Capacity in Scrum refers to the total development time available for a given Sprint. It is calculated from the number of team members, the number of working days in the Sprint, the hours available per day, and the adjustments needed for planned and unplanned absences. The output is a realistic picture of how much work the team can take on — not how much they would like to take on, or how much stakeholders would like them to take on.

Getting capacity right is one of the less glamorous and more consequential disciplines in Scrum. Teams that consistently overcommit burn out. Teams that consistently undercommit underdeliver. Neither outcome is good, and both are avoidable with straightforward capacity planning.

How to calculate capacity

The calculation has several components:

Team member availability. Start with the list of team members who will participate in the Sprint. For each person, note any planned absences: annual leave, public holidays, training days, company events. A two-week Sprint with one team member absent for three days has meaningfully different capacity from a Sprint with the same team fully present.

Sprint duration. The number of working days in the Sprint, excluding planned absences, gives you the raw time available.

Working hours per day. Typically seven or eight hours, but worth confirming — particularly in organisations with variable working patterns.

Focus factor. This is the adjustment that makes capacity planning realistic rather than optimistic. Not all available hours are available for Sprint work. Meetings not related to the Sprint, administrative work, unexpected interruptions, and general overhead consume time that does not appear in any plan. Most teams find that 60–80% of available hours are actually available for Sprint delivery. The focus factor converts theoretical availability into practical capacity.

The resulting number — available hours multiplied by focus factor — is the capacity to plan against.

Capacity-based vs velocity-based planning

There are two common approaches to Sprint planning. Capacity-based planning uses the calculation above to determine how much work to take in. Velocity-based planning uses the team's historical average story points per Sprint as the planning input.

Both have merit. Capacity-based planning is more useful for new teams without velocity history, for Sprints with unusual patterns of availability, or for teams working with uncommonly complex or variable items. Velocity-based planning is more useful for established teams with stable composition and reasonably consistent work types.

The two approaches can also be combined: velocity provides a starting point, and capacity calculations provide a sanity check — particularly when Sprint capacity is significantly different from the historical average due to holidays or absences.

Why capacity planning matters beyond the numbers

The conversations that capacity planning requires are often as valuable as the calculations themselves. The act of working through availability as a team — discussing who is available when, what other demands exist on people's time, and what a realistic Sprint looks like — builds shared understanding of the constraints the team is actually working within.

This transparency helps in two directions. Internally, it reduces the frustration that comes from committing to work that was never achievable given actual availability. Externally, it gives stakeholders a realistic picture of what the team can deliver — which, while occasionally uncomfortable to communicate, produces more trust over time than consistently overpromising and underdelivering.

Sustainable pace — one of Agile's principles — requires accurate capacity planning. The team that knows its real capacity can commit confidently, work steadily, and deliver consistently Sprint after Sprint. The team that ignores capacity and commits aspirationally tends toward burnout, deteriorating quality, and the kind of unpredictability that erodes confidence in both directions.