How to Calculate Sprint Capacity
The classic sprint capacity formula multiplies people by days by hours. It is simple, precise-looking and usually wrong. Here is a calculation that starts from what the team actually completes and subtracts what is already spoken for.
68 issues of demand against 57 typically completed: about 11 more than the team has recently delivered — before any interrupts.
Plan capacity after inherited work: carryover consumes the sprint before any new commitment is made.
What sprint capacity is
Sprint capacity is how much *new* work a team can reasonably commit to in the next sprint. It is not the team’s total output — it is what is left of typical output after work that is already in flight and work that will arrive unplanned.
Available for new work ≈ median throughput − existing WIP − typical unplanned workEach term comes from data the team already has: completed work per sprint, unfinished work in the current sprint, and the share of past delivery that arrived after sprint start.
Why the hour-based formula fails
The common formula is `people × days × hours × focus factor`. It fails in one predictable direction: too high. It assumes that when an engineer is “available”, work can progress. In practice a large share of an item’s elapsed time is spent waiting — for code review, for QA, for a release, for an answer from product. Hour math also ignores the unfinished work the team carries into the sprint.
Historical throughput has none of these problems: it is what actually got done, with all the waiting, interruptions and meetings already included.
How to calculate sprint capacity step by step
Demand = carried-in work + new commitment = 24 + 44 = 68 issues, against a median of 57 completed
- Median throughput. Completed issues or points in each of the last six to ten closed sprints; take the median.
- Existing WIP. Unfinished work in the current sprint that will carry over. Count it at its full estimate — partial progress on an issue is not reliably measurable.
- Typical unplanned share. Of completed work in recent sprints, what share was added after sprint start? Multiply by median throughput.
- Subtract. Median − existing WIP − typical unplanned work = room for new commitment.
- Adjust for known disruptions. Holidays, on-call rotations and planned leave reduce capacity; apply them explicitly and say so.
| Input | Value |
|---|---|
| Median throughput (last 6 sprints) | 48 points |
| Existing WIP carrying in | 18 points |
| Typical unplanned share (20% of 48) | ≈ 10 points |
| Room for new commitment | ≈ 20 points |
If P75 throughput is 55, a plan of up to about 27 new points is a stretch the team has achieved in its better sprints.
Adjusting for holidays and team changes
Historical throughput reflects the team as it was. When a sprint is known to be different — a public holiday, two people on leave, a new joiner still onboarding, an on-call rotation landing on the team — scale the median down proportionally and say so in the plan. Resist the opposite adjustment: a new hire rarely adds capacity in their first sprints, because onboarding consumes the time of the people already there. When the team composition changes permanently, give it three or four sprints before treating the new throughput as the baseline.
How to interpret the result
- Small room for new work is a finding, not a failure. It usually means carryover or unplanned work is consuming the sprint; that is where to look.
- Use the range, not a single number. Median is the anchor; P75 is the upper end of typical delivery.
- Expect variation. A team with throughput between 40 and 55 will land anywhere in that band for reasons unrelated to effort.
Apply this to your team’s delivery
Create a free account, set up your organization and project, then import a Jira CSV. Start with the available evidence; add sprint dates and history for stronger analysis.
Common mistakes
- Counting carryover as already planned and therefore “free”. It still takes capacity.
- Using the average. One outlier sprint distorts it; use the median.
- Converting points to hours. Points are relative size, not time.
- Planning per person. Summing individual capacities ignores the dependencies between people that dominate delivery.
- Assuming bugs are unplanned. Planned bug work is planned; measure unplanned work by when it entered the sprint.
Leadership implications and questions to ask
When the calculation shows little room for new work, the leadership question is what to stop, finish or defer — not how to squeeze more in. Protecting a realistic commitment builds predictability, which stakeholders value more than ambitious plans that slip.
Questions engineering managers should ask
- How much of the next sprint is already taken by existing WIP?
- Is our unplanned share stable, or growing?
- Are we planning to the median or to the best sprint?
- What known disruptions (holidays, on-call, launches) should reduce this sprint’s plan?
Worked example
Throughput over six sprints: 44, 51, 48, 13, 52, 47 points. Median 47.5; mean 42.5, dragged down by a release-freeze sprint. The current sprint has 18 points unfinished. On average 18% of completed work was unplanned (about 9 points). Room for new work: 47.5 − 18 − 9 ≈ 20 points. The product backlog proposes 35. The team commits to 20, marks 8 more as stretch, and leaves the rest in the backlog — a conversation that happens at planning instead of at the sprint review.
Related metrics and how the Capacity & Commitment report helps
See it on your own data in the Capacity & commitment report.
See also engineering capacity planning, engineering throughput, planned vs unplanned work and the commitment simulator.
The Capacity & Commitment report calculates median and P75 throughput, existing WIP and unplanned share from your Jira export, and recalculates proposed demand as you change the plan.
Frequently asked questions
- What is a good focus factor for sprint capacity?
- Rather than choosing a focus factor, use historical throughput: it already reflects meetings, interrupts and waiting time.
- How do I count partially finished work in capacity?
- Count it at its full estimate. A Jira export cannot show how much of a started issue remains, and guessing adds false precision.
- How many sprints of history should I use?
- Six to ten recent sprints. Fewer than three cannot describe a range.
Related guides
Engineering capacity planning
A practical guide to engineering team capacity planning: capacity vs velocity and throughput, carryover and existing WIP, planned vs unplanned work, median throughput, and the mistakes that make sprints overcommit.
Capacity planning
Plan sprint commitments against historical throughput ranges instead of optimistic capacity math. Include existing WIP and typical scope growth, and communicate risk honestly.
Engineering throughput
What engineering throughput is, how to calculate it from Jira in issues or points, why median and P75 beat averages, what flat throughput under rising demand means, and why throughput is a team measure.
Planned vs unplanned work
How to measure planned vs unplanned engineering work from Jira by when work entered the sprint — not by issue type — why bugs are not automatically unplanned, and how to reserve capacity for unplanned work.