Sprint commitment accuracy

Sprint commitment accuracy is the percentage of committed work a team finishes within a sprint, measured against what it committed to deliver at sprint planning. If a team commits to 40 story points and completes 34 of them, its commitment accuracy is 85%. The metric answers a simple question: when this team says it will deliver something, how often does it actually happen.

The value is in predictability, not raw speed. A team that delivers 30 points every sprint and commits to exactly 30 is more useful to the business than a team that swings between 20 and 50. Stakeholders can build roadmaps, set customer expectations, and sequence dependent work around a predictable team. They cannot plan around a team whose output is a guess.

Commitment accuracy is distinct from how much work gets done. A team can have high sprint velocity and poor commitment accuracy if it routinely overcommits and leaves work unfinished. The two metrics are read together: velocity tells you the volume, commitment accuracy tells you whether the forecast can be trusted.

The calculation divides the committed work that was completed by the work committed at the start of the sprint, then multiplies by 100. The inputs are simple, but defining them cleanly is where most teams go wrong.

1. 1

   Work committed at sprint start

   The total story points or item count the team agreed to in sprint planning, captured before the first day of work. This is the denominator and it must be frozen. If it moves, the metric loses meaning.

2. 2

   Committed work completed

   The committed points or items that met the definition of done by the end of the sprint. Partially finished items count as zero, because half a feature ships nothing.

3. 3

   Scope added mid-sprint

   Work pulled in after planning. Track this separately rather than adding it to the commitment, so you can see how often the plan is disturbed and by how much.

4. 4

   Scope removed mid-sprint

   Committed work that was descoped or deprioritised during the sprint. Recording removals reveals whether the team is missing the commitment or quietly trimming it to look on track.

Read the number as a band, not a target. A team landing between 80% and 100% across several sprints is reliable. Consistently above 100% means the team is sandbagging its commitment and leaving capacity on the table. Consistently below 70% means the planning process is broken and downstream teams cannot trust the forecast. The trend across sprints matters far more than any single reading.

A metric tree decomposes commitment accuracy into the causes that make a forecast right or wrong, then connects each cause to the practice that controls it. This turns a retrospective number into a list of things to fix.

The first level separates the two ways a commitment fails: the estimate was wrong, or the sprint was disrupted. Estimation quality breaks down into how well the team sizes work and how stable its understanding of the work is. Disruption breaks down into scope injected mid-sprint, unplanned support and incidents, and people becoming unavailable. Each branch points at a different owner and a different intervention.

This structure lets you diagnose a miss precisely. A team that hits its estimates but keeps getting pulled onto incidents does not have an estimation problem, it has a protection problem, and the fix sits with whoever controls interrupt load. A team with stable sprints but wildly variable estimates needs better refinement, not more discipline on focus.

There is no universal target, because a healthy band depends on team maturity and how volatile the work is. The useful benchmark is consistency: a team that lands in a tight range every sprint is performing well, almost regardless of the exact number.

Treat any reading from a single sprint with suspicion. One bad sprint caused by a major incident says nothing about the planning process. A rolling average over the last five or six sprints filters out the noise and shows whether the underlying forecast is reliable or drifting.

Improving commitment accuracy is about tightening the gap between what a team forecasts and what it delivers. That means better estimates, fewer disruptions, and an honest commitment that reflects real capacity rather than wishful planning.

The metric tree approach starts by finding which branch causes the most lost commitment, then fixing that one before touching anything else. A team that loses ten points a sprint to incidents will gain nothing from a refinement workshop. The data tells you where the leak is.

KPI Tree lets you model this by connecting each branch of the commitment accuracy tree to the role that owns it. The team lead owns refinement and estimation. The product owner owns scope discipline. The on-call rota owner owns interrupt load. With RACI ownership on every node, a missed sprint stops being a vague team failure and becomes a specific, accountable signal. When commitment accuracy drops, the accountable owner is told, and the verified impact loop checks whether the change they made actually moved the number back.

1. 1

   Letting the commitment move

   If the denominator changes when work is added or removed mid-sprint, the metric always reads near 100% and tells you nothing. Freeze the commitment at planning and track changes separately.

2. 2

   Counting partial work as progress

   An item that is 80% done delivers nothing to a user. Commitment accuracy must count only work that met the definition of done. Partial credit hides chronic overcommitment.

3. 3

   Treating it as a productivity target

   Pushing teams to hit 100% every sprint teaches them to sandbag. The goal is an honest, stable forecast, not a perfect score. Punishing misses just trains people to commit to less.

4. 4

   Reading single sprints in isolation

   One sprint wrecked by an outage is noise, not signal. Judge the metric on a rolling average across several sprints so a single disruption does not drive a wrong conclusion.

5. 5

   Ignoring why work was missed

   The number alone does not fix anything. Without separating estimation misses from disruption, teams keep applying the wrong remedy and the accuracy never improves.