Sprint planning with realistic capacity: include the work nobody counts

The team leaves Sprint Planning with a full list of work. A week later, progress looks different from the forecast. Someone has planned leave, support requests have arrived and a review queue needs attention.

These activities are part of the work. If planning leaves them out, the forecast can put pressure on people before delivery has even started.

Capacity describes the time and availability the team can realistically bring to a period of work. Use it to support a conversation about what is achievable, alongside uncertainty, skills and dependencies.

Start with the goal and actual availability

In Scrum, the Sprint Goal is the objective for the Sprint. The Developers select the work they believe they can complete, informed by factors including past performance, upcoming capacity and the Definition of Done, the shared description of required quality.

The Scrum Guide does not require a particular capacity formula. The calculation below is an optional planning aid. It should help the team see constraints, not become a target for filling every hour.

Ask what is different this time. Leave, training, on-call responsibilities and a colleague joining the team can all affect the forecast. Consider whether the necessary skills are available when they are needed.

Make the less visible work explicit

1. Count known commitments once

Start from an agreed definition of available time. If lunch or recurring meetings have already been removed, do not subtract them again.

List planned leave and other commitments using the same units. Keep the calculation at a useful team level. You do not need an individual minute-by-minute performance record to identify a planning constraint.

2. Discuss support and interruptions

Use recent experience to estimate the support work the team commonly handles. Separate known obligations from uncertain requests.

If one person is on support duty, discuss how that affects the work requiring their specialist knowledge. A team total can hide the fact that the only person able to review a particular change has little availability.

Agree how urgent requests will be assessed. If additional work arrives, make the trade-off visible rather than treating it as free capacity.

3. Include review and completion

Work needs more than an initial implementation. Testing, review, integration and documentation may be necessary before it meets the Definition of Done.

Include those activities in your view of the new work. If existing review obligations are counted separately, make sure you are not also counting them within the same items.

AI-generated code still needs appropriate checking. Faster drafting does not establish that the rest of the workflow has become faster.

4. Examine dependencies

Some work needs an answer, service or review from outside the team. Identify when it is needed and what happens if it is late.

Availability and elapsed time are different. Even a task needing little active effort can take several days if it waits for a decision. Discuss the dependency before treating the item as straightforward.

An illustrative capacity calculation

Imagine four people available across five working days, using seven scheduled working hours per person per day. That gives 4 × 5 × 7 = 140 hours, with lunch already excluded and the commitments below still included.

Planned leave: 14 hours.
Meetings and learning commitments: 16 hours.
Expected support duty: 12 hours.
Reviews for work already started: 8 hours.

This leaves 140 − 14 − 16 − 12 − 8 = 90 hours for the other planned work. The figures are fictional and illustrative, not recommended allowances.

The new work still needs its own testing and review within that remaining availability. The team must also consider specialist availability, uncertainty and the Sprint Goal. Ninety hours is not an instruction to select exactly ninety hours of tasks.

Use the numbers to have a better conversation

Try: “These are the commitments already drawing on the team’s time. Which work best supports the goal within that picture, and where are the biggest uncertainties?”

If someone asks to add another item, ask what changes in the forecast. Options might include reducing scope, changing the sequence or reassessing a dependency. Avoid treating overtime as an unspoken planning assumption.

After the Sprint, compare your assumptions with what happened. Investigate recurring patterns without blaming people for reporting them.