Engineering Delivery Metrics Leadership Actually Needs
Engineering organizations rarely lack metrics. They lack metrics organized around the questions leadership actually asks. Start from the questions, and the right metrics — and the right level of detail — follow.
Part of Engineering Delivery Intelligence: better planning and fewer surprises
This guide answers
- Are we on track?
- What changed?
- Where is delivery slowing down?
- What actually shipped?
- What should we change next sprint?
Five questions, and the metrics that answer them
- Are we on track?
- Progress
- Remaining work
- Stage distribution
- What changed?
- Scope added
- Scope removed
- Priority changes
- Where is delivery slowing down?
- Code review
- QA
- Blocked work
- Aging
- What actually shipped?
- Done
- Released
- Production delivery
- What should we change next sprint?
- Carryover
- Historical throughput
- Scope growth
- Chronic work
Every metric on a leadership view should answer one of these questions. If it answers none, drop it.
This structure does two things. It keeps the leadership view small — a handful of metrics per question. And it makes the purpose of each metric explicit, which is the best protection against it being misused.
Are we on track? Progress, remaining work and stage distribution
Progress alone (percent complete) is not enough — see how to reduce delivery surprises. Pair it with remaining work by stage, so leadership can see whether what is left is nearly finished (in QA) or barely started. Mid-sprint, add the work at risk: not started, blocked and aging.
What changed? Scope added, removed and reprioritized
Report original commitment next to current scope, with additions and removals listed separately and the reason for each. This is the metric that most often explains a missed sprint, and the one most often left out. See how scope changes affect sprint outcomes.
- Scope added — issues entering after the start, with the day they arrived and why.
- Scope removed — issues taken out, which still count against the original plan.
- Priority changes — work reordered inside the sprint; less visible, but often the reason planned work did not start.
A leadership view does not need every change, just the size, the timing and the main reasons. A line such as “+18 (+28%): incident follow-ups and support escalations; nothing removed” is enough to change how the rest of the numbers are read.
Where is delivery slowing down? Queues, aging and blocked work
now usual for this point in a sprint
Leadership does not need every stage metric — just where work is accumulating beyond normal.
Show stages that are above their usual level, how long work has been there, and what blocked work is waiting on. The bottlenecks guide explains how to read these without jumping to conclusions.
What actually shipped? Done vs released
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.
Engineering complete, QA complete and released are three different milestones — report all three.
Leadership and customers care about what reached production. Report released work separately from done, and watch the gap between them: a growing “done but not released” pile is invisible in most engineering metrics and very visible to customers.
What should we change next sprint? Carryover, throughput and chronic work
The planning metrics look backward to improve the next plan: demonstrated throughput over several sprints, carryover by stage at close, typical scope growth, and issues carried three or more times. The sprint predictability guide shows how they fit together.
| Metric | The decision it informs |
|---|---|
| Historical throughput (range) | How much to commit to next sprint |
| Carryover by stage at close | Whether to fix planning, flow or dependencies |
| Typical scope growth | How much room to leave for unplanned work |
| Chronic carryover | Which issues need a split, an unblock or a stop |
These are the metrics that turn a retrospective into a planning change. Without them, the next sprint is planned the same way as the last one — and ends the same way.
Metrics that mislead leadership
Misleading at leadership level
- Story points per person
- Velocity compared across teams
- Lines of code, commits
- A single composite health score
- Percent complete without scope
Useful at leadership level
- Original plan completed
- Scope change with reasons
- Queues vs their usual level
- Released vs done
- Chronic carryover
Metrics that rank people or compress everything into one number tend to change behaviour, not delivery.
The metrics on the left are easy to collect and easy to game. Once people know they are judged by them, the numbers improve and delivery does not. The metrics on the right describe the delivery system, which is what leadership can actually change.
A one-page leadership view
Checkout team · Sprint 24
Partially delivered- On track?
- 64%of original plan
- What changed?
- +18added mid-sprint
- Slowing down?
- 18in QA and review
- Shipped?
- 38released
- Change next?
- 6chronic issues
Summary
- Engineering throughput normal; testing and release did not keep pace with +28% scope.
- Next sprint: plan against throughput, add testing capacity, decide on chronic items.
One card per team. Five questions, answered in numbers, with the evidence one click away.
For how to turn this into a written update, see the engineering status report guide.
See this in VeloWise: Sprint health and trends
Each leadership question maps to a VeloWise report: Sprint progress, Scope change, Bottlenecks, Epic delivery and Historical trends, all from one dataset.
Works with the sample project or your own data. VeloWise currently imports delivery data from delivery data exports.
Go deeper
Frequently asked questions
- What engineering metrics should executives see?
- A small set tied to their questions: progress against the original plan, scope change, where work is slowing, what was released, and the carryover and throughput trends that inform the next plan.
- Are DORA metrics enough for engineering leadership?
- DORA metrics describe deployment performance and stability. They complement sprint-level delivery metrics — commitment, scope change, carryover — rather than replacing them.
- How many metrics should a leadership dashboard have?
- As few as answer the questions: typically one to three per question. If a metric does not change a decision, it does not belong on the leadership view.
Related guides
Sprint Health: Metrics That Help Explain Whether Delivery Is on Track
Sprint health is several signals, not one score: commitment, scope growth, progress, carryover, stage distribution, aging, blocked work and release.
How to Measure and Improve Sprint Predictability
Predictability is more than completed ÷ planned. Read commitment, scope growth, carryover and chronic work together to make sprints dependable.
Software Delivery Workflows: From Backlog to Production
How software delivery workflows work: common stages, seven workflow models and their trade-offs, active vs waiting work, bottlenecks, and choosing one.
How to Create an Engineering Status Report Leadership Can Actually Use
A sprint status report leadership reads in a minute: outcome, what changed, where work is, risks and a short summary — with an example.
Sprint Commitment vs Completion: What the Numbers Really Tell You
When commitment rises and completed work stays flat, the plan — not the team — is drifting. How to read the gap and plan the next sprint.