Questions: When should an organization scale its Agile implementation? Should an organization new to Agile start with a scaling framework or get Scrum right first?
Who is taking control of the Scrum Board/Software (say e.g. JIRA) ? The PO or the Scrum Master ? Talking about the backlog items selected for the sprint, does the developer choose und pull the task himself from the overall backlog into the Sprint Backlog or does the SM or PO does that, who has the overall control of the tool ? Also, the time necessary or Story Points have to be given by the PO prior to the Spring Goal while grooming his Backlog or is hat open to discussion still in the Sprint Planning or only if one or more Developers don`t agree with the value given by the PO ?
Developers own the Sprint Backlog so anything related to that in a tool is theirs. Be careful about how velocity is viewed: th-cam.com/video/EaNDvNEOMWs/w-d-xo.html. It's not grooming it's refinement 😊
On my last team, I (for better or worse) was the focal point for Sprint Planning. I had to keep a tight reign on the team - holding them to the process, keeping them focused, asking questions to provoke meaningful discussion, etc. Without it, the team would spend excessive amounts of time going down rabbit holes, trying to change the scope and focus of what we were doing, etc. We ran two-week sprints and sprint planning would routinely take 6-9 hours (often over two days). It was extremely stressful and burned me out within 12 months.
@@DaishaView I know, hahaha With regards to that, I'll suggest they have a better product backlog refinement session (PBR), that way team has an in depth understanding of the user stories and task, make sure they INVEST criteria and all what not. Reason I'm mentioning this is because; one of the main reason why sprint planning sessions tend to be long is because the PBR session wasn't conducted efficiently thus creating room for a lot of catching up work. Also, as the SM I'll suggest you have a discussion with the P.O before the sprint planning meeting to make sure he has a full understanding of the sprint goal of the upcoming sprint, specifying what value needs to be attained.
hi! Can you share more about using Liberating structure to figure out your Sprint Goal? :)
Upvote :D
These are awesome guys.
Important video
Thanks
Questions: When should an organization scale its Agile implementation? Should an organization new to Agile start with a scaling framework or get Scrum right first?
Who is taking control of the Scrum Board/Software (say e.g. JIRA) ? The PO or the Scrum Master ? Talking about the backlog items selected for the sprint, does the developer choose und pull the task himself from the overall backlog into the Sprint Backlog or does the SM or PO does that, who has the overall control of the tool ?
Also, the time necessary or Story Points have to be given by the PO prior to the Spring Goal while grooming his Backlog or is hat open to discussion still in the Sprint Planning or only if one or more Developers don`t agree with the value given by the PO ?
Developers own the Sprint Backlog so anything related to that in a tool is theirs.
Be careful about how velocity is viewed: th-cam.com/video/EaNDvNEOMWs/w-d-xo.html.
It's not grooming it's refinement 😊
@@AgileforHumans Hillarious !! :-)
On my last team, I (for better or worse) was the focal point for Sprint Planning. I had to keep a tight reign on the team - holding them to the process, keeping them focused, asking questions to provoke meaningful discussion, etc. Without it, the team would spend excessive amounts of time going down rabbit holes, trying to change the scope and focus of what we were doing, etc. We ran two-week sprints and sprint planning would routinely take 6-9 hours (often over two days). It was extremely stressful and burned me out within 12 months.
were you an SM or lead developer of the team. Just want to know from the perspectives of both.
@@MN-gs2nn I was the SM.
@@mamarine81 thank you for your reply.
6-9 hours?! Goodness!
@@DaishaView I know, hahaha
With regards to that, I'll suggest they have a better product backlog refinement session
(PBR), that way team has an in depth understanding of the user stories and task, make sure they INVEST criteria and all what not. Reason I'm mentioning this is because; one of the main reason why sprint planning sessions tend to be long is because the PBR session wasn't conducted efficiently thus creating room for a lot of catching up work.
Also, as the SM I'll suggest you have a discussion with the P.O before the sprint planning meeting to make sure he has a full understanding of the sprint goal of the upcoming sprint, specifying what value needs to be attained.