Software Delivery Metrics That Help Instead of Hurt
Delivery metrics are useful when they help a team see its own system and decide what to change. They become harmful when they are used to rank people or become targets. This guide covers which metrics to use, where the data comes from, and how to keep them honest.
- Not started
- Development
- Code review
- QA / testing
- Done
- Released
- Open
- To Do
- Backlog
- In Development
- In Progress
- PR Review
- Code Review
- Ready for QA
- In Test
- UAT
- Closed
- Resolved
- Production
- Deployed
Jira statuses (top) differ from team to team. Each maps to one delivery stage, so “work waiting for review” means the same thing everywhere.
Delivery metrics are only comparable once statuses mean the same thing — normalise first, then measure.
How this is calculated: The normalized delivery model in the methodology
The main families of delivery metrics
| Family | Metrics | Answers |
|---|---|---|
| Sprint predictability | Completion of commitment, scope growth, carryover | Can others rely on our plans? |
| Flow | Throughput, cycle time, work item age, WIP | How fast and how smoothly does work move? |
| Bottlenecks | Queue size and time per stage | Where does work wait? |
| DORA | Deployment frequency, lead time for changes, change failure rate, time to restore | How safely and quickly do we ship to production? |
Sprint and flow metrics come from the work tracker (Jira). DORA metrics come from deployment and incident systems — a Jira export alone cannot produce them honestly.
Why they matter
Without data, delivery conversations default to anecdote and the loudest opinion. With a small set of well-understood metrics, a team can see its constraint, test a change and know whether it worked. Leaders get predictability without micromanagement.
Most delivery outcomes are properties of the system — how work is planned, sized, reviewed, tested and released — rather than of individual effort. Metrics that describe the system point to changes a team can make together. Metrics about individuals point to blame, and people respond by gaming them.
Where each metric's data comes from
| Metric | Standard Jira CSV | Needs more |
|---|---|---|
| Throughput | Yes (resolved dates) | — |
| Carryover | Yes (multi-value Sprint field) | Reasons for older sprints need status history |
| Scope growth | Lower bound (with sprint dates) | Exact needs Sprint field history |
| Lead time | Yes (created → resolved) | — |
| Cycle time / time per stage | No | Status change history |
| Work item age | Partial (Status Category Changed) | Status history for exact start |
| DORA metrics | No | CI/CD and incident data |
Throughput = items completed per sprint (or per week)How to interpret them together
Business Profile epic
- Development complete
- 92%
- QA complete
- 68%
- Released
- 42%
Engineering completion ≠ production delivery. Development complete counts work past development; QA complete counts done and released; released counts only what reached production.
A Jira “% done” can say 92% while only 42% of the epic has reached customers — delivery has milestones after engineering.
- Read metrics as pairs: throughput with cycle time, completion with scope growth, carryover with its reasons.
- Watch trends and variability over 4–8 sprints rather than single values.
- Compare a team with its own history. Cross-team comparisons of points or velocity are meaningless.
- Prefer percentiles to averages for anything time-based.
Leading and lagging indicators
Completion, throughput and cycle time are lagging: they describe work that has already finished. Work item age, queue size in wait stages and carried-in WIP are leading: they show problems forming while there is still time to act. A healthy review looks at both — lagging metrics to judge whether a change worked, leading ones to steer the current sprint.
When a measure becomes a target, it ceases to be a good measure. — Goodhart’s law, as commonly paraphrased
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
- Individual-level metrics. They distort behaviour and measure the wrong unit: delivery is a team property.
- Vanity metrics. Total tickets closed, lines of code, commits — high numbers that do not inform a decision.
- Too many metrics. Five well-understood ones beat twenty dashboards.
- Charts the data cannot support. Stage timing from a CSV without history; probabilities from five sprints.
- Targets. "Velocity must increase 10%" guarantees point inflation.
A sensible starting set
- Completion of original commitment and scope growth — predictability.
- Carryover rate with reasons — where plans break down.
- Throughput range — for planning.
- Cycle time percentiles and aging WIP — flow (requires status history).
- DORA metrics from your deployment pipeline — production delivery.
Review them in retrospectives and planning, not in performance reviews.
When introducing metrics to a team, start by showing the team its own data and asking what surprises them. Agree on definitions before anyone looks at trends, and commit publicly that the numbers will not be used to compare individuals or teams. Metrics the team owns get used; metrics imposed from above get gamed.
Example
A director reviewing four teams stops comparing velocity and instead asks each team for completion of commitment, carryover reasons and the largest queue at close. One team has a release-cadence problem, one is over-committing, and two are healthy. Each conversation is shorter and ends with a concrete change.
Three months later, the over-committing team plans against its historical median and its completion rate has moved from around 55% to around 80% — with the same throughput. Nothing about the team's effort changed; the plan started matching reality. That is the kind of improvement delivery metrics are for, and it would have been invisible on a velocity chart.
How this tool helps
See it on your own data in the Sprint health report.
This tool covers the sprint predictability, flow and bottleneck families from a Jira export, is explicit about what each export can and cannot support, and keeps your data on your device. See how every metric is calculated.
Frequently asked questions
- Can Jira data produce DORA metrics?
- Not reliably. DORA metrics describe deployments and incidents, which live in CI/CD and incident tools rather than in sprint tickets.
- Which delivery metric matters most?
- For sprint-based teams, completion of the original commitment paired with its explanation (scope change, carryover reasons) is usually the most decision-relevant.
Related guides
Sprint health
A practical guide to sprint health for engineering managers: commitment reliability, scope change, carryover and throughput — how to calculate them from Jira and what to do about them.
Cycle time
What cycle time is, how it differs from lead time, how to calculate median and percentiles from Jira, why averages mislead, and why a CSV export alone cannot give you time per stage.
Engineering bottlenecks
How to find delivery bottlenecks in an engineering workflow using queue size and time-in-stage, why arbitrary red/amber/green thresholds mislead, and what to do once you find the constraint.
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.