When a team uses the capacity technique in Sprint Planning, the Product Owner brings the highest-value Product Backlog items into the event and describes them to the team, usually starting with an overview of the set of items and their relationship to the Product Goal.
Capacity-driven planning is also referred to as commitment-driven planning.
Team members select a first item to bring into the Sprint. This will almost always be the Product Owner’s top-value item.
Team members discuss the work involved, and identify the tasks that will be necessary to deliver the Product Backlog item and meet the Definition of Done within the Sprint.
Do not ask or expect a team to think of every task that will be done during the sprint. Not only is that impossible, it is also unnecessary.
Teams should think of enough of the tasks that they feel they have thought through the work and how to achieve the Definition of Done.
After the team identifies tasks and has estimated the Product Backlog item (not the tasks), the team members ask themselves, “Can we realistically achieve this?”, and “can we complete this by the end of the Sprint?”
It is very important that the team members ask this collectively of themselves rather than having a Scrum Master or Product Owner for a firm commitment. Importantly, the team commits to:
Scrum demands courage in a full-team commitment:
If the team is confident they can deliver a Product Backlog item, they select another item and repeat the process. And they continue repeating it until someone says that they’ve reached capacity.
If someone says the item cannot be completed within the Sprint, team members will generally discuss the situation and see if someone else is available to help —perhaps a DBA with rudimentary JavaScript skills can help an overwhelmed JavaScript developer.
If not, perhaps that item can be returned to the Product Backlog and a smaller item can be brought in.
The four steps of capacity-driven planning only requires an assessment of whether the team feels it has reached its capacity and can firmly commit to delivering the work to achieve the Sprint Goal. It does not require an assessment of previous velocity as a proxy for future capacity.
They do, however, play an important role in the final step of a Sprint Planning event.
While many teams find that giving Product Backlog items a quick, high-level estimates in Story Points, neither Story Points nor Velocity play a role in capacity-driven Sprint Planning (as described by Mike Cohn).
Once team members have filled their available capacity in the Sprint, the team can look at the selected Product Backlog items, sum the Story Points assigned to each, and share the results. Team members can then compare it to the average or recent Velocity.
Example One:
Suppose a team with an average Velocity of 20 conducts a capacity-driven Sprint Planning meeting and selects 19 points of work. They’ve done this without knowing the Story Point values on any of the selected Product Backlog items.
When their Scrum Master facilitating the event tells them they’ve just selected 19 points of work and have an average Velocity of 19, that team should feel very confident they’ve selected an appropriate amount of work for the Sprint.
Example Two:
Suppose instead, though, that the Scrum Master for this team announces they’ve selected only 11 points of work. They might in that case ask themselves why they were making the work so hard during Sprint Planning as compared to when they’d earlier estimated the same items in Story Points.
For example, this may reveal that during sprint planning they’d identified work they’d earlier not thought about, or perhaps had explicitly assumed would not be part of a given story. Or they may discover that the story really is harder than they’d thought when assigning points to it.
Either way, knowing they’d selected 11 yet averaged 20 will help the team know they’ve selected an appropriate amount of work or perhaps make a change to bring more.
Example Three:
Similarly, if the Scrum Master announces that the team has selected 30 points, 10 more than their average Velocity, team members may wonder what they are forgetting to consider. “Why,” they would discuss, “does this work seem so much easier after sprint planning than it did while estimating Story Points?”
Story Points and Velocity do not play a role during the main portion of a capacity-driven Sprint Planning event. But they play the vital role of acting as a sanity check and confirmation of the plan.
1. Cohn, M. (2014) 7) Capacity-Driven Sprint Planning. Online at: https://www.mountaingoatsoftware.com/blog/capacity-driven-sprint-planning
All fields are required.
