Jira Sprint Health: The Metrics That Actually Explain a Sprint

What sprint health means

Sprint health is not a single number. It is a small set of measures that together answer one question: did the sprint go the way we planned, and if not, why not? A healthy sprint is one where the commitment made at planning was realistic, the plan stayed mostly stable, and work flowed through to done without piling up in a queue.

The useful measures fall into three groups:

• Commitment reliability — how much of the original commitment was completed.
• Stability — how much the scope changed after the sprint started, and how much work carried in or out.
• Flow — throughput, cycle time, and where unfinished work was sitting when the sprint closed.

Velocity (points completed) belongs in the flow group, but on its own it is the least informative of these. Two sprints with the same velocity can have completely different stories: one delivered exactly what it planned; the other abandoned half its plan to fight an incident and backfilled with small bugs.

Why it matters

Stakeholders plan around sprint commitments. When a team routinely completes 60% of what it commits to, the damage is not the missing 40% — it is that nobody downstream can trust the plan. Product managers pad dates, leadership asks for status more often, and the team spends more time explaining than delivering.

Sprint health metrics turn the retro conversation from "it felt like a rough sprint" into "we added 11 issues after day three and four of them were production bugs". That second sentence leads to a decision. The first leads to a shrug.

How to calculate the core sprint health metrics

Two details matter more than they appear to. First, count issues as well as points — points hide the fact that a sprint "completed 80%" by finishing the small items and leaving the three large ones. Second, measure completion against the original commitment, not the final scope. Completion against final scope rewards adding easy work mid-sprint.

Completion of commitment = completed original issues ÷ original commitment

How to interpret the numbers

Look at trends over four to six sprints before reacting to one. A single bad sprint is usually an event (an incident, a holiday, a dependency). A pattern is a system.

• Completion consistently below ~70% usually points to over-commitment or chronic disruption, not to a lack of effort.
• High scope growth with decent throughput means the team is busy but the plan is not protecting its priorities.
• Rising carryover is the leading indicator to watch: each sprint starts with less real capacity than the last.
• Stable throughput with falling completion means planning is drifting away from reality — the team is delivering the same amount while promising more.

A team that completes 75% of its commitment every sprint is more predictable than one that swings between 40% and 100%. Predictability, not maximum output, is what sprint health measures.

Common mistakes

• Using velocity as a target. Once points become a goal, estimates inflate and the metric stops describing anything.
• Comparing teams on velocity. Point scales are team-local. Compare each team to its own history.
• Ignoring issue counts. A sprint can hit its point total while leaving every large, risky item unfinished.
• Counting completion against final scope. It hides scope creep and makes disrupted sprints look healthy.
• Reporting a Jira burndown as a health metric. Burndowns show the shape of a sprint but not the causes.
• Assuming the CSV knows more than it does. A standard Jira CSV has no sprint dates and no status history. Any "time in review" figure computed from it alone is invented.

What engineering managers can do about it

1. Plan against historical throughput, not capacity estimates. If the team has completed 30–38 issues in its last six sprints, a 50-issue commitment is a wish.
2. Make mid-sprint additions an explicit trade: something of similar size comes out, and the swap is recorded.
3. Review the largest queue at sprint close in every retro. It is the most direct pointer to the constraint.
4. Track carryover by reason, not just as a percentage. "Waiting for release" and "still in development" need very different fixes.
5. Show stakeholders the range, not a single number. "We typically complete 30–38 issues" sets better expectations than "we will do 34".

Example

A checkout team commits to 36 issues. During the sprint, 9 are added (4 production bugs, 5 stakeholder requests) and 2 are removed. At close, 25 of the original 36 are done, plus 6 of the additions.

Velocity alone (31 issues) says this was an average sprint. The health view says something more useful: the team delivered its usual amount, but a fifth of that capacity went to unplanned work, and that — not execution — is why the commitment was missed.

How this tool helps

See it on your own data in the Sprint health report.

The sprint health dashboard calculates all of these from a Jira CSV export, shows each against the previous sprint and the three-sprint median, and labels every number as Observed, Inferred or Unavailable depending on what your export contains. If you do not have Jira data handy, try the sample project. Analysis runs in your browser; imports made with an active organization project are also stored for your team. Read the data-handling guide.

Frequently asked questions

What is a good sprint completion rate?

There is no universal target. Many stable teams complete 70–90% of their original commitment. More important than the level is consistency: a team that reliably completes about 80% can plan around it.

Is velocity a sprint health metric?

Velocity is a throughput measure. It is useful for planning ranges but says nothing about whether the plan held. Pair it with completion of commitment, scope growth and carryover.

Can I measure sprint health from a Jira CSV export?

Partly. Carryover and completion work from the Sprint field. Scope change needs sprint dates (and ideally Sprint field history). Time-in-stage metrics need status-transition history, which a standard CSV does not include.

Related guides

• 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.

• 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.

• Jira sprint report

  What a useful sprint report contains beyond the Jira burndown: commitment, scope change, carryover reasons, the constraint, and one or two decisions — with evidence levels stated.

• Software delivery metrics

  A leader's guide to software delivery metrics: flow metrics, sprint predictability and DORA, what each can and cannot tell you, and how to avoid turning metrics into targets.