Sprint Capacity Planning with Historical Ranges, Not Guesses
Capacity planning usually starts with "how many people for how many days" and ends with a commitment the team has never once delivered. Planning against what the team has actually completed is simpler and far more reliable.
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 history-based capacity planning is
Instead of deriving capacity from headcount and hours, you look at how much the team completed in recent sprints — in issues and in points — and describe it as a range: minimum, lower quartile, median, upper quartile, maximum. The proposed commitment is then compared with that range.
Why it works better
Jira velocity and sprint reports describe completed work. Capacity planning also needs the unfinished work you inherit, expected interrupts, availability changes and stage-specific constraints. Ten engineers do not create ten interchangeable units of review or QA capacity. Use historical output as a range, then discuss what is different about the next sprint.
Historical throughput already includes everything capacity math forgets: meetings, interrupts, reviews, context switching, sick days and production support. It is the team's real delivery rate, measured.
Capacity math fails in a predictable direction. "Six engineers × ten days × a 70% focus factor" produces a number that feels conservative, but it silently assumes that work flows without waiting — that reviews happen immediately, QA is available on demand and nothing is blocked. Real sprints are full of waiting, which is why capacity-based plans are almost always too large and history-based ones are not.
This is decision support, not prediction. The honest statement is "in 6 of 8 sprints we completed at least this much", not "there is a 75% probability we will finish".
How to calculate a planning range
Demand = carried-in work + new commitment = 24 + 44 = 68 issues, against a median of 57 completed
- Collect completed issues and points for the last 6–10 closed sprints.
- Compute median, P25 and P75 (with fewer than three sprints, do not pretend there is a range).
- Add existing WIP — work that will carry into the sprint — to the proposed new work.
- Optionally add typical scope growth: median net growth × proposed work.
- Compare the total load with the historical range.
Planning load = proposed work + expected carry-in + expected mid-sprint growthPoints or issues?
Plan in whichever unit the team estimates consistently. Issue counts are often surprisingly stable because they are immune to estimation drift, and they work even when some work is unestimated. Points help when item sizes vary a lot. Either way, compare the proposal with history in the same unit — never points against a count.
How much history to use
Six to ten recent sprints is usually enough. Older sprints may reflect a different team, codebase or process, and a single exceptional sprint (a release backlog being cleared, a holiday) should not define the range. Look at the median and the middle half (P25–P75); treat the maximum as a curiosity, not a target.
| Load vs history | Reading |
|---|---|
| ≤ P25 | Conservative — likely to finish with room for interrupts |
| P25 – median | Typical |
| median – P75 | Stretch — achievable in the team's better sprints |
| P75 – max | Above typical — only the best sprints delivered this |
| > max | Beyond anything observed |
How to interpret the result
Sprint 20
60 → 56gap 4
Sprint 21
65 → 57gap 8
Sprint 22
72 → 58gap 14
Sprint 23
78 → 59gap 19
- Committed ↑ +18
- Completed → +3
When commitment keeps rising and demonstrated throughput does not, carryover follows — plan against what the team has actually completed.
- A stretch plan is fine if the team and stakeholders agree which items are the stretch.
- An above typical plan should come with an explicit list of what drops first.
- A plan beyond history needs a reason to believe this sprint is different — a smaller release, fewer interrupts, more people — stated out loud.
- Throughput from a sprint that ended a release freeze (a burst of deployments) will inflate the maximum. Look at the median, not the peak.
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
- Forgetting carried-in work. It is the most common reason commitments are missed on day one.
- Planning to the best sprint ever. The maximum is an outlier by definition.
- Mixing units. Plan in points or in issues, and compare with history in the same unit.
- Presenting a probability. Five to ten sprints cannot support one. Ranges and counts are honest.
- Ignoring known disruptions. A sprint with a public holiday or a planned incident rotation should be planned below the median, not at it.
- Treating the plan as fixed. When the team loses a person for a week, re-plan; do not keep an obsolete commitment and explain the miss later.
What engineering managers can do
- Bring the historical range to sprint planning and show where the proposal lands.
- Put carried-in work at the top of the plan.
- Agree a visible stretch line: everything below it is the commitment.
- Re-plan after disruptions instead of keeping an obsolete commitment.
Example
History: median 49 points, P75 51, maximum 119 (a sprint that shipped a release backlog). Proposed: 64 points, plus about 20 points of in-progress work that will carry in. Load is 84 points — above the P75 and above everything but the one outlier sprint. The team keeps the top 40 points as the commitment and marks the rest as stretch.
How this tool helps
See it on your own data in the Capacity & commitment report.
The commitment simulator lets you add and remove proposed issues, include existing WIP and typical scope growth, and immediately see where the load lands against your own historical delivery.
For the wider picture — how commitment has compared with delivery across sprints, how much of each sprint was carryover, and how much work arrived unplanned — use the Capacity & Commitment report. The engineering capacity planning guide covers the concepts.
Frequently asked questions
- How many sprints of history do I need?
- At least three closed sprints to describe a range, and six to ten for a stable one. Older history may not reflect the current team.
- Should I plan in story points or issue counts?
- Either works if you compare like with like. Issue counts are often more stable because they are not subject to estimation drift.
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.
Sprint capacity
A step-by-step method for calculating sprint capacity from historical throughput: median delivery, existing WIP, room for unplanned work, and why hour-based capacity formulas overcommit teams.
Sprint scope creep
How to measure sprint scope creep from Jira — original commitment, added, removed, net growth — why CSV exports undercount it, and how engineering managers can control it.
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.