May 19, 2026
5 min read
Data-driven sprint planning
Sprint Planning Based on Capacity
How to base sprint planning on real team capacity instead of abstract ambition or average historical output.
Start with the room the team actually has
Capacity-based sprint planning starts with the room the team actually has this sprint: time off, part-time contributors, meetings, support load, and realistic focus time.
Capacity should shape the sprint before velocity, habit, or pressure gets a vote. Otherwise the team is planning around a fantasy version of the next two weeks.
Capacity-based planning
Capacity helps only when it can actually shape the sprint before the commitment gets locked in.
Capacity first
The plan should start from the sprint's real room, not an ideal target.
Availability
Who is really present for this sprint matters first.
Focus time
Usable delivery time is not the same as hours on the clock.
Known load
Meetings, support, and absences must reduce the scope before the sprint starts.
Realistic scope
Capacity-based planning is useful when it changes what the team commits to.
What teams usually get wrong
Teams often inherit a target from past sprints, then retrofit the people to match the number.
That reverses the planning logic. Instead of asking what the current sprint can honestly carry, the team starts with a desired amount of work and tries to make the capacity story fit afterward.
Why historical output is not enough
Historical output can be useful context, but it does not know who is on vacation, who is part-time, how much support load is expected, or whether this sprint has unusual meeting pressure.
That is why velocity or past completion patterns should challenge the plan, not replace the current capacity check.
Start with availability
The first planning move is to count who is really available for the sprint and how much of their time can actually contribute to delivery.
Full-time, part-time, shared, and absent team members should not all be treated as the same kind of capacity.
Adjust for interruptions and focus factor
Raw availability still overstates the sprint if the team ignores recurring meetings, support work, coordination load, and context switching.
Focus factor helps turn calendar time into usable delivery time so the team plans from reality instead of idealized hours.
Then decide what work fits
Once the team understands the real sprint room, it can decide how much work fits more honestly.
That changes the conversation from “how much should we take?” to “given the room we actually have, what commitment can we defend?”
- Start with actual capacity, not idealized availability.
- Separate confident work from higher-risk work.
- Use recent delivery history as a planning check.
- Make assumptions visible before commitment leaves the room.
Where to go next
If your sprint planning rarely starts from actual room, the capacity tool is the best next step.
That is where the team can account for availability, time off, focus time, and support load before deciding what work belongs in the sprint.
TL;DR
- Capacity-based planning starts with the real room available this sprint.
- Past output is useful context, but it should not replace current capacity.
- Availability, focus factor, support load, and uncertainty should shape scope before commitment.
- Capacity-based planning works when capacity is allowed to shrink the sprint before overload becomes inevitable.