Capacity and commitment: how much to take into a Sprint

Every Sprint Planning contains the same quiet argument. The Product Owner wants more in. The Developers know what the last Sprint felt like. Someone says "we can stretch". The Sprint ends with a story at 80 per cent and a team that is tired and a little less trusting of its own plans. Capacity and commitment are the vocabulary for having that argument with evidence.

Two numbers, two questions

Capacity asks how much working time the team will actually have in this Sprint. It is about people and calendars: who is on holiday, which days are lost to public holidays or training, how much of each person's day goes to meetings and support rather than Sprint work.

Velocity asks how much the team has finished in comparable past Sprints, in the unit it uses to size work. It is about history, and it carries information that capacity does not, such as how long things really take and how much unplanned work the team usually absorbs. Our post on how velocity gets misused covers what it is and is not.

The Scrum Guide points at both without naming them. It says the more the Developers know about their past performance, their upcoming capacity and their Definition of Done, the more confident they will be in their Sprint forecasts. The SBOK® Guide goes further about the history half: the previous Sprint velocity becomes the most important factor in determining how much the team can commit to next, provided changes in the situation since the last Sprint are accounted for.

Used together, they check each other. If velocity says 24 points and capacity says the team will have 60 per cent of its usual days, a plan for 24 is probably wrong. If capacity looks normal and the plan is 40, the plan is probably wrong in the other direction.

A worked example

An invented four-person team runs two-week Sprints. In its last three Sprints it finished 22, 25 and 24 points. Its typical velocity is about 24.

For the coming Sprint, one Developer is away for three days and there is a public holiday. The team has 40 working days in a normal Sprint (4 people times 10 days) and 36 this time, which is 90 per cent. Scaling the velocity by that gives about 21 or 22 points as a starting figure.

The Product Owner would like a 26-point story set. The team reviews the options.

• Take 26. That is more than the best of the last three Sprints, in a short-staffed Sprint.
• Take 22. It matches the adjusted evidence and leaves little buffer.
• Take 20 and name two stretch items. The team commits to the goal with 20 points and lists two more it will pull in if things go well.

The third is the common-sense choice: a goal that is safe, with a visible way to do more. None of this needed a formula, only the two numbers and a conversation.

Forecast or commitment

The words matter more than they seem. The Scrum Guide says the Developers select items from the Product Backlog to include in the Sprint, and speaks of Sprint forecasts. What is committed is the Sprint Goal: although the Sprint Goal is a commitment by the Developers, it provides flexibility in the exact work needed.

The SBOK uses the stronger word for the items. In its Commit User Stories process, the team commits to a subset of the estimated user stories that it believes it can complete, based on team velocity, and the stories must be chosen according to the Product Owner's priorities. It also says that once the Sprint Backlog is finalised and committed to, new stories should not be added, and new requirements go on the Prioritized Product Backlog.

The two are compatible if you read them carefully. The team commits to the outcome it has promised, and the exact items are a best estimate. A team that treats the list as an iron promise has an incentive to inflate estimates and hide problems. A team that treats the goal as the promise can say, on day six, "this story is bigger than we thought, and here is what we propose to drop to keep the goal".

How to size the selection

A sequence we would suggest, not one either source prescribes:

1. Start from the goal. What do we want true at the end of the Sprint?
2. Pick the items in order from the top of the backlog that serve it, as far as the Product Owner's ordering allows.
3. Sum the sizes and compare with velocity, adjusted for capacity.
4. Check the dependencies. An item that depends on something outside the team is a risk to the plan.
5. Look at the Definition of Done. If it includes testing and deployment, those are part of the size.
6. Leave a margin. Unplanned work is a fact, and a plan with no slack turns every surprise into a missed commitment.

The SBOK sets the planning meeting time-box at two hours per week of Sprint. The Scrum Guide's maximum is eight hours for a one-month Sprint. Both aim to keep planning short enough to be useful.

What overcommitting costs

• Stories at 80 per cent. Work that does not meet the Definition of Done does not count. It returns to the Product Backlog, and the Sprint delivers less than a modest plan would have.
• Corners cut. The Guide says quality does not decrease during the Sprint. Under pressure, testing and review are the first things squeezed.
• Eroded trust. When the team misses its forecast repeatedly, stakeholders stop believing forecasts, and the team stops making honest ones.
• A self-reinforcing cycle. Missed Sprints lower velocity, which tempts someone to ask for a higher target.

Undercommitting has a cost too, but a smaller one. A team that finishes early can pull in the next item from the top of the backlog, and nothing breaks.

Common mistakes

• Using the best Sprint as the baseline. Plan from the typical result, not the peak.
• Ignoring capacity. Velocity is blind to holidays.
• Letting someone outside decide the number. The Developers select what to take on. The Product Owner orders, and the team forecasts.
• Counting hours and points at once. Pick one unit for planning and stay with it.
• Adding work mid-Sprint to fill gaps. Only add what serves the goal, and only with the Product Owner.
• No stretch list. Without one, a team that finishes early either idles or invents work.

How to practise it

In the simulator, the second step runs planning poker, and the gate asks how much you commit the team to, against its capacity. Committing beyond it is possible, and the Sprint's outcome shows what that costs.