Sprint Commitment vs Team Capacity: Why Teams Overcommit and How to Stop
When a team misses its sprint commitment for the fifth time, the instinct is to ask why the team was slow. The data usually says something else: the sprint started with more work than the team has ever completed.
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.
How this is calculated: Commitment rising, throughput flat in the methodology
What commitment and capacity mean here
Sprint commitment is the work in the sprint when it starts: carried-in work plus new work committed at planning. Team capacity is how much work the team typically completes, best described by median throughput and its range.
Commitment accuracy is the share of the original commitment that was completed. It measures planning, not people.
Commitment accuracy = original commitment completed ÷ original commitmentWhy commitment drifts above capacity
- Carryover compounds. Each missed sprint pushes work into the next, which then starts heavier and misses again.
- New commitment is planned in isolation. Planning focuses on the backlog items being added, not on the total load.
- Demand grows while throughput is flat. Roadmap pressure raises the plan; delivery does not change because the constraint (review, QA, release) did not change.
- Scope enters after planning. Incidents and requests are absorbed without anything leaving.
The pattern is recognisable in a single chart: committed work per sprint rising, completed work per sprint flat. It is an organisational planning problem, and leaders own the fix.
How to measure it
Expected carryover ≈ commitment − demonstrated throughput = 78 − 58 (median of 56, 57, 58, 59) ≈ 20 issues
- For each closed sprint, record original commitment split into carryover in and new commitment.
- Record completed work and original commitment completed.
- Compare median commitment with median completed over the last six sprints.
- Count how many sprints committed more than they completed.
| Sprint | Carryover in | New | Committed | Completed | Accuracy |
|---|---|---|---|---|---|
| S15 | 54 | 50 | 104 | 51 | 49% |
| S18 | 12 | 47 | 59 | 48 | 78% |
| S19 | 13 | 54 | 67 | 44 | 60% |
| S20 | 30 | 59 | 89 | 52 | 56% |
Here new commitment grows modestly (47 → 59) but total commitment grows fast (59 → 89) because carryover grows. Throughput stays at 44–52.
Separate the two completion rates
Two completion figures answer different questions. Completion of the original commitment (original work completed ÷ original commitment) asks whether the plan held. Completion of final scope (everything completed ÷ everything in the sprint at close) asks how much of the sprint’s total workload got done, including work added mid-sprint. A team can score low on the first and high on the second when it spent the sprint on urgent unplanned work — which is a planning and intake conversation, not a delivery one.
How to interpret commitment vs capacity
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.
- Commitment consistently above completed: the plan, not the team, is the variable to change.
- Accuracy falling while throughput is flat: commitment is rising; check carryover and new work separately.
- Accuracy low but throughput high: lots of unplanned work is being completed; see planned vs unplanned work.
- Accuracy high every sprint: the team may be sandbagging; check whether it regularly pulls in more work mid-sprint.
Commitment accuracy describes a planning system. The moment it becomes a target for engineers, it stops being useful.
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
- Treating accuracy as a performance score. Teams will pad plans and stop pulling in extra work.
- Looking only at new commitment. Carryover is where overcommitment hides.
- Blaming the team for flat throughput. Flat throughput under growing demand usually reflects a constraint in the system.
- Committing to the requested scope. The request is demand; capacity is what the team has shown it delivers.
- Fixing accuracy by padding. Adding hidden buffer inflates estimates and makes the next plan less honest; show the buffer explicitly instead.
- Reviewing only the last sprint. One sprint is noise. Look at six before concluding the plan is systematically too large.
Leadership implications and questions to ask
Leaders set the conditions for honest commitments: they decide how much roadmap pressure reaches a sprint, whether unfinished work can be deprioritised, and whether a smaller, reliable commitment is rewarded over an ambitious one that slips.
Questions engineering managers should ask
- Are we planning based on requested scope rather than demonstrated delivery capacity?
- Is existing WIP being accounted for before committing new work?
- Has commitment grown while throughput stayed flat — and what constraint explains the flat throughput?
- What will we explicitly not do this sprint?
Example
Over six sprints, median commitment was 91 points and median delivery 49.5 — commitment exceeded delivery in every sprint. The team was not slowing down; the plan was growing. The director introduced one rule: carried-in work is reviewed first at planning and either finished, split or returned to the backlog before new work is added. Two sprints later, commitment was 60 and accuracy rose above 75%.
Related metrics and how the Capacity & Commitment report helps
See it on your own data in the Capacity & commitment report.
Related: Jira carryover, how to reduce sprint carryover, why sprints fail and sprint forensics.
The Capacity & Commitment report makes this pattern visible in its primary chart — committed (carryover + new) vs completed — and states how many recent sprints committed more than they delivered, with every number traceable to Jira issues.
Frequently asked questions
- What is a good commitment accuracy?
- There is no universal target. Consistency matters more than the level: a team that reliably completes about 80% of its commitment can plan around it.
- Should commitment accuracy be tracked per engineer?
- No. Commitment is a team planning decision; per-person accuracy measures ticket assignment, not contribution.
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 carryover
How to calculate sprint carryover from a Jira export, classify it by reason (review, QA, release, blocked), and tell the difference between observed and inferred causes.
Reduce carryover
A practical, evidence-first playbook for reducing sprint carryover: diagnose by stage, right-size commitments, limit WIP, and fix the constraint instead of pushing harder.
Why sprints fail
The recurring, measurable reasons sprints miss their commitments — over-commitment, scope creep, review and QA queues, release backlogs, dependencies, unclear requirements — and how to tell them apart with data.