Who Runs Sprint Planning?
ฝัง
- เผยแพร่เมื่อ 21 ก.ค. 2024
- Who runs the sprint planning meeting? Discover the answer to that question and more in this video short.
Everyone on the Scrum team has a role to play in the sprint planning meeting.
00:00 The Scrum Master's role in sprint planning
00:10 The product owner's role in sprint planning
00:24 The developers' role in sprint planning
00:34 What to do when the sprint seems full
Thanks Mike for the video and giving a practical suggestion on this ,
I gotta say it is an interesting
But I must add I am not sure that is the only practice this can work at least if we wanna make sure we wanna be loyal to the principles (I said principled not practices) of Scrum .
The leading question that drives our conversations would be: Why is this Sprint valuable?
The Product Owner proposes how the product could increase its value and utility in the current Sprint.
The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is
valuable to stakeholders.
When we say collaboration : does that mean that the sprint goal input only comes from the PO so that dev start figuring out what pbi to pull that would help address that goal ?
(maybe ) but not necessarily , one could also argue that it needs to be challenged in order for true collaboration to happen
What if the product owner underestimated tech implication on the value of the current sprint
What if the devs realized that the sprint goal did not Take into account what the inputs and current unrealized value emerged from From the last sprint review with stakeholders
My point is : the key word is collaboration and collaboration in complex environments comes in many shapes and form .What you described is one way to address it among many .
Thanks again 😊 Mike
I love challenging those who I am a fan of
And thanks for helping us succeed with Agility
Thanks for your thoughtful comment. There are probably very few things that can only be done one way.
As needed...
Hi Mike, thank you for the nice explanation!! 😊
Regarding sprint planning, as SM and if the teams use past average velocity as reference to plan, I have a dilema on a story point velocity average proposal and people on going on holidays ( or even having more meetings than usual, spikes,etc), if the relationship of past less capacity and velocity should be taken into account for a correct amount of story points proposal in a future sprint planning based on mathematics, how is best to do?
So let’s say:
Sprint 1 : 100 points (all team present)
Sprint 2 : 50 points ( 60% of the team is present, this is 60% of the total working hours for that team due to holidays)
Sprint 3 : 100 points ( all the team present)
Average velocity: 250/3 = 83 points
So now I go to planning Sprint 4 but only 50% of the team is present. Would you still use 83 points as average reference to plan which includes past holidays or any form of less capacity?
Is there some mathematics to use to suggest some number to plan? or only ask the team how they “feel “about it?
Or does it make sense to do the following?
Sprint 1 = 100 points ( all team)
Sprint 2 = 84points (50 points /0,6), this is a number adjusted to full capacity as if the whole team would have been present.
Sprint 3 = 100 points ( all team present)
Average adjusted to full capacity: 284/3 = 95 points
So in sprint 4 if 50% of the team is present, then I would propose in planning = 95 *0,5 = 48 points.
Does this makes sense?
Or just average 83 points*0,5 = 41 points to propose in planning?
I see the correlation between past average velocity and past capacity. In the same example if in sprint 4 planning all the team were present, possibly planning something between 95 and 100 points would have more sense than 83 points?
How you handle average velocity of sprints when some included a past decreased capacity? (like absences or sprints with more meetings than usual or spikes, etc) to use to propose in planning for next sprint in a mathematical way?
I hope I am understood.? 😅
Hi Alexander, Yes, I understand your question but have no answer for it. You're describing one of the many, many problems with velocity-based sprint planning. I never recommend teams plan that way. Instead I recommend planning sprints by capacity. Doing so completely eliminates this and related problems. I am the world's biggest fan of velocity but only when looking ahead over multiple sprints in release or milestone planning. See this blog why I don't recommend velocity-driven sprint planning. www.mountaingoatsoftware.com/blog/why-i-prefer-capacity-driven-sprint-planning
@@MountainGoatSoftware Hi Mike,
Thank you so much for the quick answer. I am wondering in “practice” how the capacity based planning is done. For what I understand normally then you want to see tasks under the story in hours and check on the capacity of the team, I have seen tutorials in TH-cam using JiRa and some add ons in which this is based on the availability of each team member on excel sheets then estimating tasks in hours of stories and subtract those hours to the available hours on a specific team member individually (this availability is based on holidays, team meetings, focus factors, etc) until reaching all hours for the team, but then if doing so, the meeting ends up pre assigning tasks to each team members beforehand until filling the whole teams capacity in hours.
This is not a good for team accountability and also not that effective since the To Do list in the scrum board will be pre assigned, meaning that is a team member gets delayed or sick none other team member will “not” take his/her next tasks in the board which possibly corresponded to a higher priority story. The daily stand up becomes a less collaborative meeting. So the “To Do” column should be a pull column of unassigned stories/tasks to deliver faster following kanban principles.
I see that you somehow agree on this here th-cam.com/video/Nm352yhG64M/w-d-xo.htmlsi=wOPFlCkDY69VCnlS but again how can then in 90 minutes (2 weeks sprint) the team can look at possible tasks from user stories and subtract hours from capacity without thinking or detracting the hours on each individual but on group level?
Additionally, then hours could be an individual measure which vary from developer to developer (so ends up being individual?), that is the reason of better with relative sizing?
So in practice how your spread sheet calculation for sprint capacity planning would look like so that you start subtracting hours from tasks until meeting the capacity without thinking of individuals?
Is not this very time consuming to make it in 90 minutes?
@@alexanderleanzabhnsdalen8847 That's very close to how capacity based planning works. But instead of breaking everything down to an individual level, like having each team member say how many hours they have available in a spreadsheet, have the whole team in the planning session. Bring in the prioritized backlog and have your devs pick an item and ask "Can we commit to this item? Do we have the capacity this sprint to bring in and commit to completing this item?" Let the team discuss and come to a conclusion. If the dev team decides that they can bring in the item, congratulations! Your team just committed to an item! Repeat that process until the team says "We think we're full for this Sprint"
The team should be able to look ahead and see what schedule conflicts there might be in the upcoming sprint (holidays, team meetings, Dr. appointments, etc) and take them into account when discussing each item. It's also up to the team to decide how they'll do the work.
In the video that you linked to I discussed if a team should assign individuals to a task or not. The point that I was trying to make was that if a team member doesn't feel individual responsibilities for their own work, then the team should assign individuals to tasks. After personal responsibility has been engrained into the team, then assigning tasks is no longer needed. when that happens, you can use your daily scrum to have team members indicate what tasks they will work on each day.
Regardless of how tasks are assigned in planning, the team should have a pretty good idea about what tasks need to be done for each story and how much total time the team has to commit to those stories. You can use that task list to quickly validate that the team has enough time in the sprint to complete everything that they brought in (or want to bring in) by asking the team to quickly provide a time estimate of how long each task will take. This time estimate shouldn't take more than 15 seconds for each task and should be thrown away after this validation is done. If you have a team that has 100 total hours available to work this sprint; and after they did a quick time estimate for each task found that they have 130 total hours of work ahead of them, then the team is over capacity and needs to remove some stories.