Deploy free

Sprint planning accuracy: what the say-do ratio actually tells you

Iteration Planning Accuracy plots one bar per closed Jira sprint or ADO iteration — the % of committed issues that actually finished Done, Closed, or Resolved by the end — against a fixed 80% target line. This is a sprint planning accuracy metric, not a productivity one. It doesn't care how much got done. It cares whether the team's word is good.

deckgauge · Board · Intelligence
Target 80%

Six iterations of say-do accuracy against the 80% target.

What it measures, and where the data comes from

One bar per closed iteration — this widget never scores a sprint that's still in flight. For each one, it takes everything committed at the start and checks what fraction actually reached a done-family status (Done, Closed, or Resolved) by the time the iteration closed. Higher accuracy is better. The bar's height has nothing to do with how much work got done — a team that commits to five things and finishes four scores the same 80% as a team that commits to fifty and finishes forty.

  • Jira — committed vs. completed issues for each closed sprint.
  • Azure DevOps — the same comparison over closed iterations.
Why not GitHub or GitLabThis widget needs a sprint or iteration boundary to define "committed at the start" versus "finished by the end." GitHub Issues and GitLab Issues have no such boundary, so this one only lights up for boards synced from Jira or ADO with sprints configured. It reads 4, 8, or 12 iterations back — configurable per board, 8 by default.

How to read it

The target line is fixed at 80% — not a suggestion, a deliberately chosen number. Industry guidance on the say-do ratio consistently lands healthy teams in the 80-90% band: high enough that a stakeholder can plan around a commitment, low enough that the team isn't quietly sandbagging to guarantee a green number every time. A bar sitting right at the line is doing its job. A bar near 100%, iteration after iteration, isn't a better score — it's usually a team committing to less than it's capable of so the chart never embarrasses anyone.

What you're actually looking for is the gap between the bars and the line, and which direction it's trending. Below the line means the team is over-promising at planning, not under-performing at execution — those are very different problems with very different fixes.

What it tells you over time

One low iteration is a Tuesday — someone got pulled onto a fire, a dependency slipped, scope got added mid-flight. Don't touch process for that. What matters is the run: three, four, five iterations in a row sitting below the line is not bad luck, it's the planning process itself producing commitments the team can't keep. Track the trend in the bars, not any single reading.

Example situations

1. Chronic over-commitment, sprint after sprint

deckgauge · Iteration Planning Accuracy
Target 80%

Six iterations, none of them clearing the target.

What you're seeing: six bars in a row, all sitting well under the target, none of them recovering. Stakeholders have started hedging every date the team gives them, and they're right to — the plan hasn't matched the delivery in over a month.

How to react: resist the instinct to lean on the team to "just deliver more." The bars are below the line because planning is setting a number the team can't hit, not because people are slacking. Check Velocity with Confidence alongside this one — a wide confidence band usually means estimates were never calibrated to begin with.

Managerial playCommit to less on purpose for the next two or three iterations — plan against the lower end of what the team has actually shown it can finish, not what it hopes to finish. Tighten refinement before the iteration starts: a ticket that isn't broken down and understood shouldn't get committed, full stop. Then stop talking about the miss and start talking about the rebuild — tell stakeholders explicitly that the next few iterations are smaller on purpose, so the number they see recovering means what they think it means.

2. Accuracy climbing after tighter refinement

deckgauge · Iteration Planning Accuracy
Target 80%

Weak start, then a clean run above target.

What you're seeing: three rough iterations, then a visible step up, holding above the target for the last three. Something changed at the midpoint — most likely a refinement process getting tighter, or scope discipline improving mid-sprint.

How to react: the temptation is to move straight on to the next fire. Don't. A recovery like this is worth naming out loud — in the retro, in the stakeholder update, wherever the team gets credit for things. If nobody says what changed, the habit that fixed it quietly erodes the first time the team is under pressure again.

Managerial playWrite down what specifically changed between iteration 3 and iteration 4 — tighter Definition of Ready, smaller stories, an extra refinement pass — while everyone still remembers it, not three months later when it's folklore. Keep the target at 80%, don't quietly raise it just because the team is clearing it; a string of bars sitting suspiciously near 100% is the next thing to watch for. Protect whatever process change got you here before the next deadline crunch tempts everyone to skip it "just this once."

Frequently asked

What is sprint planning accuracy, or the say-do ratio?
The percentage of issues committed at the start of a closed Jira sprint or Azure DevOps iteration that actually reached Done, Closed or Resolved by the end, plotted as one bar per iteration against a fixed 80% target line.
Is planning accuracy a productivity metric?
No. It does not care how much got done. It measures whether the team's commitment is reliable, which is a forecasting question rather than an output one.
What does chronic over-commitment look like?
Bars consistently sitting well below the target line iteration after iteration. The fix is committing to less, not working harder — a team that reliably hits 80% is more useful to plan around than one that occasionally hits 100%.

Related widgets

Last updated