How to Do Sprint Capacity Planning

Most sprint overcommitment is not optimism about the work. It is arithmetic that was never performed. The team has ten working days and five people, someone multiplies, and fifty person-days becomes the plan for a sprint that will actually deliver around thirty.

This guide covers why the gap exists, how to calculate capacity properly, how to find your team's real focus factor, and how to use the number in planning.

Quick answer: Sprint capacity is calculated by counting each person's available days, subtracting leave and known commitments, then applying a focus factor — typically 60 to 75 percent — to account for meetings, support and interruptions. The resulting number is almost always lower than teams expect, which is precisely why the calculation is worth doing.

Why Teams Overcommit Every Sprint

Teams overcommit because they plan against contracted hours rather than available ones, use last sprint's velocity without adjusting for this sprint's absences, and let carryover disguise how large the gap has become.

Each of these is straightforward to correct once named.

Contracted hours are not available hours

A full-time developer is contracted for around forty hours a week. The proportion of that going to sprint work is considerably lower.

Standups, planning, review, retrospective, refinement, one-to-ones, company meetings, code review of other people's work, interviewing candidates, answering support questions, onboarding a new joiner — none of these is waste, and all of them consume the day. Planning as though they do not exist guarantees a shortfall every sprint.

Last sprint's velocity is not next sprint's capacity

Velocity tells you what the team delivered under last sprint's conditions. Capacity tells you what conditions apply next sprint.

If two people are on leave, there is a public holiday and someone is on support rotation, historical velocity overstates what is achievable. Velocity is the starting point; capacity is the adjustment. Teams that use velocity alone commit to the same amount every sprint regardless of who is actually present.

Carryover hides the real number

When a sprint ends with three unfinished items, they roll into the next sprint. Because they are partially complete, the team treats them as small, and takes on a full sprint of new work alongside them.

The overcommitment compounds quietly. Two or three sprints in, the team is carrying a permanent backlog of half-done work and nobody can say what the actual delivery rate is.

Persistent carryover is the clearest available signal that capacity planning is not happening.

Capacity Planning Inputs and Adjustments

Input Typical effect How to find it Sprint length Baseline Sprint calendar Team size Baseline Team roster Annual leave Direct subtraction Leave calendar Public holidays Direct subtraction Calendar Scrum ceremonies 5–10% reduction Meeting schedule Other meetings 5–15% reduction Calendar audit Support / on-call 10–30% reduction Ticket history Onboarding a new joiner Reduces two people Known in advance Focus factor (combined) 60–75% of nominal Historical measurement

How to Calculate Sprint Capacity Step by Step

Count available days per person, subtract leave and known commitments, apply your focus factor, then convert the result into whatever unit you plan in.

Step 1: Count available days per person

Start with the sprint length in working days and list each team member individually. A two-week sprint gives ten working days per person before any adjustment.

Do this per person rather than as a team average. Averages hide the part-time developer and the person on leave for half the sprint, and those are exactly the details that make the plan wrong.

Step 2: Subtract known commitments

Remove annual leave, public holidays, training days, and anything else already committed.

Also remove time for known non-sprint duties: the person on support rotation, the one interviewing three candidates this week, the one onboarding a new joiner. Onboarding is worth calling out specifically, because it reduces the capacity of two people — the joiner and whoever is helping them — for several sprints.

Step 3: Apply your focus factor

Multiply the remaining days by your focus factor, the proportion of time historically spent on sprint work.

Most teams land between 60 and 75 percent. Use your own measured figure rather than a benchmark. A team with heavy support duties may be at 50; a protected team with few meetings may reach 80. The number is a property of your environment, not a target to hit.

Step 4: Convert to your planning unit

If you plan in hours, multiply the adjusted days by hours per day. If you plan in story points, use the ratio between your normal capacity and your normal velocity to scale.

For example, if a full-capacity sprint typically delivers thirty points and this sprint has 80 percent of normal capacity, plan for around twenty-four. This keeps points as relative sizing while making the commitment reflect who is actually available.

Finding Your Team's Real Focus Factor

Measure your focus factor from what actually happened over several sprints rather than assuming an industry figure, understand where the missing time goes, and recalculate when the team changes.

Measure it rather than assuming it

For three sprints, record nominal available days and compare against what was genuinely spent on sprint work. The ratio is your focus factor.

You do not need precise time tracking. A rough estimate from each person at sprint end — roughly what share of your time went to sprint work — is accurate enough and takes two minutes. The figure will surprise most teams, and that surprise is the point.

What eats the missing time

The usual contributors, roughly in order of size: meetings beyond scrum ceremonies, support and interruptions, code review of colleagues' work, and context switching between tasks.

Understanding the breakdown is useful beyond planning. If half your missing time is meetings, that is addressable. If it is support load, you may need a rotation so it lands on one person rather than fragmenting everyone's week.

Recalculating after team changes

Focus factor shifts when circumstances change. A new joiner, a change in support arrangements, a reorganisation that adds meetings — each moves the number.

Recheck after any significant change, and expect two or three sprints of instability before the new figure settles. Planning against a stale focus factor is only slightly better than not calculating at all.

Using Capacity in Sprint Planning

Fill the sprint to the calculated capacity and then stop, hold a small buffer for the predictable unexpected, and account for part-time and shared people at their real availability.

Fill to capacity, then stop

Once the sprint backlog reaches the calculated number, planning is finished. The pressure to add one more item is constant and should be resisted.

The capacity figure is a limit rather than a target. Teams that treat it as something to reach exactly will overshoot, because estimates are uncertain in both directions and only one direction gets noticed.

Leave room for the predictable unexpected

Every sprint contains something unplanned — a production issue, an urgent customer request, a dependency that arrives late. This is predictable in aggregate even though the specifics are not.

Reserve around 10 to 15 percent of capacity for it. Teams that plan to the last point spend every sprint deciding what to drop, which is a worse conversation than deciding in advance not to fill the space.

Handle part-time and shared people honestly

A person split between two teams does not deliver half a person's output to each. Context switching costs real time, so plan them at less than their nominal split — many teams use around 40 percent per team for a 50-50 split.

The same applies to anyone with a substantial non-delivery role. A tech lead spending half their time on architecture and mentoring should be planned at that reduced figure rather than as a full contributor.

Common Capacity Planning Mistakes

The three errors that undermine capacity planning are planning at full theoretical capacity, ignoring support load, and treating the capacity figure as a productivity target.

Planning to full theoretical capacity

Five people times ten days is fifty person-days on paper and roughly thirty in practice. Planning against the paper figure guarantees carryover in every single sprint.

Ignoring support and on-call load

Support work is real work and it consumes real capacity, but because it does not appear on the sprint board it is routinely excluded from the calculation.

Either subtract it explicitly from the person carrying it, or bring support items onto the board so they compete visibly with planned work. Invisible work is the most common reason a team's capacity calculation looks right and its delivery does not.

Treating capacity as a target rather than a limit

The moment capacity becomes a number management expects the team to hit, it corrupts.

Focus factors get revised upward, estimates get compressed, and the calculation stops reflecting reality.

Capacity exists to make commitments realistic. Used as a performance measure, it produces optimistic planning and the overcommitment it was meant to prevent. The signal that this is happening is a focus factor that only ever moves upward — real measurement produces a number that fluctuates in both directions as circumstances change.