Software delivery metrics for business leaders: what to track and what good looks like

Software delivery metrics tell you how quickly a team turns a decision into working software, and how often that software causes problems once users have it. For a business leader, five measures from DORA's research and three business-facing ones cover most of what you need. Review them monthly, read the trend rather than a single month, and never use them to rank teams against each other.

Why delivery metrics matter outside engineering

Most leaders judge a software team by feel: the last missed deadline, the last outage, or how confident the engineering lead sounds in meetings. That stops working once the team is remote, external or simply larger.

Metrics give both sides the same facts. They turn 'it feels slow' into a question the team can answer, such as whether changes wait a week for review or a fortnight for a test environment. They also give a good team a way to show that it is improving.

The DORA metrics in plain words

DORA is a research programme that studies how software teams deliver. It began with four key metrics and now uses five, in two groups: throughput, which shows how fast changes move, and instability, which shows how often they cause trouble. Each one is measured for a single application or service, not averaged across a whole company.

Throughput: how fast changes reach users

• Change lead time. The time from a developer committing a change to that change running in production. A long lead time usually means work is waiting somewhere: for a reviewer, a test environment or a release window.
• Deployment frequency. How often the team releases to production. Small, frequent releases are easier to check and easier to undo than one large release each quarter.
• Failed deployment recovery time. How long it takes to recover when a release goes wrong and needs urgent attention. It replaced an older measure of average recovery time, known as MTTR.

Instability: how often changes cause trouble

• Change fail rate. The share of releases that need immediate action after they go out, such as a rollback or an urgent patch.
• Deployment rework rate. The share of releases that weren't planned but happened because of a problem in production. When it is high, the team spends its time cleaning up instead of building.

The two groups keep each other honest. A team can release more often by cutting corners, but the instability numbers will show it. DORA's guide notes that top performers do well across all five metrics and low performers do poorly, so speed and stability tend to rise together. Our post on DevSecOps in the delivery pipeline shows how to add security checks without dragging these numbers down.

Three business measures to add

DORA measures the engineering pipeline. Leaders also need to know whether the team does what it said it would, and whether users get value from it. We recommend adding three measures that speak to the business directly.

Predictability

Compare what the team planned to deliver in a sprint or milestone with what it actually delivered, and track the share completed over several sprints. A team that delivers a steady share of its plan is easier to build sales and launch dates around than one that swings between heroics and misses. A perfect score every sprint can mean the team is planning too little, so look for steady rather than perfect.

Escaped defects

Count the bugs found by users or in production, rather than by the team's own testing, and sort them by severity. This is the quality number your customers feel. A rising count usually points to testing that happens too late or not at all. Our post on building a software testing strategy covers how to catch more of them before release.

Time to first value

Measure the time from approving a piece of work to the first moment a real user benefits from it, even in a small form. This joins delivery speed to business results. Picture a feature that took three weeks to build, then waited two months for a quarterly release. The business experienced a delay of nearly three months, whatever the sprint charts said.

What good looks like

No single target suits every product. A payments platform and an internal reporting tool shouldn't release at the same pace. Look for these patterns instead:

• Change lead time that is stable or shrinking, with no long waits the team can't explain.
• Releases that are small and regular, not rare and large.
• A change fail rate that holds steady or falls as releases become more frequent.
• Quick recovery from a failed release, because the team has a rollback it has actually practised.
• Predictability that stays steady from one sprint to the next.
• Escaped defects that trend down, with no repeat of the same kind of serious bug.

The direction matters more than the level. A team that cuts its lead time from three weeks to one is doing well, even if a competitor's team is faster still.

How delivery metrics get gamed

Any number tied to a reward gets bent towards the reward. This is Goodhart's law, and DORA's guide warns about it directly: don't set the metrics as goals, don't compare unrelated teams and don't make teams compete. In practice, gaming looks like this:

• Splitting releases. One change shipped in ten tiny releases lifts deployment frequency, but nothing extra reached users.
• Relabelling failures. An urgent fix logged as planned work makes the change fail rate look better on paper.
• Planning low. The team commits to less than it can do, so predictability reads 100% every sprint.
• Moving bugs out of the count. Defects get closed as duplicates or reopened as feature requests.
• Starting the clock late. Lead time is measured from when coding starts, which hides the weeks the work sat waiting.

The defence is to use metrics for questions, not performance reviews. When a number moves, ask the team why, and expect them to show you the tickets and releases behind it.

A one-page monthly dashboard

Keep it short enough to read in five minutes, and show a three-month trend for each line. A template that works:

1. Change lead time: the median for the month, and the slowest step in the process.
2. Deployment frequency: the number of production releases.
3. Change fail rate and rework rate: the share of releases that needed urgent fixes, with a one-line cause for each.
4. Recovery time: the longest and the typical recovery from a failed release.
5. Predictability: planned against delivered items for each sprint.
6. Escaped defects: the count by severity, and any cause that keeps repeating.
7. Time to first value: for the main items released this month.
8. Risks and decisions: two or three lines on what the team needs from you.

The last line is what makes the review useful. The numbers show what happened. The team's notes explain why, and what should happen next. For the weekly update that sits under this monthly view, see our post on software project status reporting.

Where to start

Don't buy a metrics platform first. Ask the team for change lead time, deployment frequency and change fail rate for the last three months, taken from tools they already use, such as the code repository and the deployment pipeline. Add escaped defects and predictability next. Then hold a monthly half-hour review and keep the same format for a full quarter before changing it.

If an outside team builds your software, ask for these numbers as part of its regular reporting. Our managed engineering squads report risks as quickly as wins, and you can see the project tools and progress at any time. To talk through your own delivery numbers, book a free 30-minute call.