VeloWiseengineering delivery intelligence

Sprint Health: Metrics That Help Explain Whether Delivery Is on Track

A “sprint health score” is tempting: one number, green or red. But a sprint can be unhealthy in several different ways, and each needs a different response. Healthy sprint reporting shows a handful of signals — and says what each one means.

Part of Engineering Delivery Intelligence: better planning and fewer surprises

For: Engineering managers, Scrum Masters, directors and product leadersUpdated

This guide answers

  • Which metrics describe sprint health?
  • Why not a single health score?
  • How do you read the signals together?

Eight signals of sprint health

Sprint 24 · health at closeExample delivery data

Sprint 24 · sprint health

Commitment
64incl. 11 carried in
Scope growth
+28%+18 issues
Progress
46 / 8264% of original plan
Carryover
366 carried 3+ sprints
Past development
64engineering complete
Aging
7longer than usual in stage
Blocked
4one shared dependency
Released
38 / 46of completed work

Healthy

  • Engineering throughput: 64 issues past development
  • 83% of completed work released

Needs attention

  • Scope +28% — well above the usual 8–15%
  • 11 in QA and 7 in review at close
  • 6 issues carrying 3+ sprints

Eight signals. Two are healthy, and three point at the same place: testing and release.

SignalQuestion it answersHealthy looks like
CommitmentWas the plan realistic?Close to demonstrated throughput, after carried-in work
Scope growthHow stable was the plan?Within the team’s usual range, with trade-offs explicit
ProgressHow much of the plan got done?Most of the original commitment completed
CarryoverHow much rolled forward?Small, and mostly late-stage work
Stage distributionWhere is work sitting?No stage holding far more than usual
AgingIs anything stuck?Few items much older than the team’s usual time in stage
Blocked workWhat is waiting on others?Few, with named owners and dates
Release progressIs done reaching users?Completed work released promptly

Why not a single sprint health score?

Two sprints · the same “health score: 72”Example delivery data

Sprint A · score 72

  • Scope stable
  • Commitment 20% above throughput
  • Carryover mostly not started

Sprint B · score 72

  • Scope +28%
  • Commitment realistic
  • Carryover mostly in QA

A composite score hides which signal moved — which is the only thing you need to know.

Composite scores average signals that should never be averaged. A realistic plan does not compensate for a QA bottleneck; stable scope does not compensate for chronic carryover. The score moves, but nobody can say what to do about it — and teams quickly learn which inputs move the score most.

If you need a single status for a portfolio view, derive it transparently — for example, “at risk if any two signals need attention” — and always show the signals next to it.

Stage distribution: where the sprint’s work actually is

Sprint 24 · all 82 issues at closeExample delivery data

82 issues in scope at close

  • Released 38
  • Done 8
  • QA 11
  • Code review 7
  • Development 8
  • Blocked 4
  • Not started 6

18 issues sat in review and QA at close — more than twice the 8 still in development.

Stage distribution is the most underused health signal. A burndown shows how much is left; the distribution shows where it is. A healthy sprint near its end has little work in early stages and a steady flow into done and released. An unhealthy one often has a bulge in review or QA — work that engineering considers finished but that has not reached users.

Aging and blocked work: the early-warning signals

Count vs ageExample delivery data

Code review · Team A

0–2 days6
3–5 days4
6–10 days8
10+ days11

29 issues — and 19 of them older than 5 days.

Code review · Team B

0–2 days18
3–5 days4
6–10 days1
10+ days0

23 issues — nearly all fresh and moving.

Count says how much work is in a stage; age says whether it is moving. Old work in a short queue can matter more than a long queue that is flowing.

Aging compares how long each in-progress issue has been in its current stage with how long this team usually takes. In Sprint 24, 7 unfinished issues were well past their usual time. Aging is the best mid-sprint predictor of carryover: an issue that has sat in QA for twice the usual time rarely finishes in the last two days.

Blocked work deserves its own line in any health view, with what it is waiting on. Four blocked issues waiting on one dependency is one escalation, not four problems.

Stage distribution is only as good as the workflow behind it. A workflow that separates waiting from active work — “waiting for QA” vs “in QA” — makes this signal far sharper; software delivery workflows explains the trade-offs.

Release progress: the signal that connects to outcomes

Sprint 24 · two views of “done”Example delivery data

  • Completed work released

    38 released46 completed83%

    8 completed issues were waiting for release at close.

  • Original commitment completed

    41 completed64 committed64%

Healthy delivery means completed work reaches production, not just the done column.

Release progress is where sprint health connects to business outcomes. If completed work regularly waits days or weeks for release, the sprint can look healthy while customers see nothing. See how to measure the real outcome of a sprint.

A ten-minute mid-sprint health check

Sprint health is most useful while there is still time to act. Halfway through the sprint, walk through these questions with the team lead — it takes about ten minutes when the numbers are already assembled:

  1. Has scope grown beyond the usual range? If so, agree what gets traded out now.
  2. Is any stage holding much more than usual? If review or QA is backing up, pause new starts and help clear it.
  3. What is aging? Pick the two oldest items and ask what they need.
  4. What is blocked, and on whom? Escalate shared dependencies once, with an owner.
  5. Is completed work being released? If “done” is piling up, talk to whoever owns releases.
  6. What is unlikely to finish? Say so now, in the leadership update.

Each question maps to one of the eight signals, and each has an action attached. That is the difference between a health check and a health score.

See this in VeloWise: Sprint health

Commitment, scope change, completion, carryover, stage distribution and release progress for every sprint, with the evidence for each number.

Open Sprint healthHow sprint health works

Works with the sample project or your own data. VeloWise currently imports delivery data from delivery data exports.

Go deeper

Frequently asked questions

What are the most important sprint health metrics?
Commitment against demonstrated throughput, scope growth, completion of the original plan, carryover by stage, aging and blocked work, and release progress. Read them together rather than ranking them.
How often should sprint health be checked?
At least mid-sprint and at close. Aging, blocked work and stage distribution are most useful mid-sprint, while there is still time to act.
Can sprint health be compared between teams?
Signals like scope growth and stage distribution can be discussed across teams, but judge each team against its own history. Workflows and work types differ too much for direct scoring.

All engineering delivery guides