The four DORA metrics are the closest thing software delivery has to a standard measurement. They are also widely misused: turned into a scorecard, compared across teams, and attached to targets.
Used that way they tell you very little. Used as a diagnostic, they point at the one thing slowing a team down. This post is about the second use.
If you want your own numbers first, the DORA Metrics Calculator takes four answers and returns a level for each metric and the one to work on.
The four metrics
| Metric | What it measures | Kind |
|---|---|---|
| Deployment frequency | How often you release to production | Throughput |
| Lead time for changes | Time from a merged commit to production | Throughput |
| Change failure rate | Share of deployments that need a fix or rollback | Stability |
| Time to restore service | How long a failed deployment stays broken | Stability |
The finding that made these famous is that throughput and stability rise together. Teams that deploy more often tend to have fewer failures, not more. Small changes are easier to review, easier to test, and easier to undo.
That is worth repeating to anyone who believes a release freeze makes things safer. A freeze makes the next release bigger.
Read them as a pattern
A single level tells you little. The combination tells you where to look.
Fast lead time, low deployment frequency. Changes are ready quickly and then wait. The constraint is the release process: a manual approval, a release calendar, a deployment that needs a specific person. Fix the process, not the engineers.
High deployment frequency, high failure rate. The pipeline is fast and lets too much through. More speed will make it worse. The work is test coverage on the paths that keep breaking, and progressive delivery so a bad change reaches a small share of traffic first.
Low failure rate, slow recovery. Failures are rare and each one is a long outage. Teams in this position often have no practised rollback, because they seldom need one. Make rollback a single command and rehearse it.
Everything slow. Start with deployment automation. A deployment that needs a runbook and a calendar slot will always be rare, and nothing else improves until it is routine.
Where changes actually wait
Lead time is the metric leaders most often misread. When it is long, the instinct is to ask engineers to work faster. Yet a change usually spends very little of its lead time being worked on.
Follow one change from merge to production and write down each wait:
- Waiting for review
- Waiting for a test run
- Waiting for a release window
- Waiting for a manual check in staging
- Waiting for someone with permission to deploy
Most teams find that two of these account for nearly all the time. Those two are the constraint. Improving anything else changes nothing.
Three ways to get it wrong
Setting targets. Tell a team to deploy daily and they will deploy daily, with empty changes if they have to. The number improves and delivery does not. Measure, discuss, and let the team choose what to fix.
Comparing teams. A team running a payments ledger and a team running a marketing site should not have the same change failure rate. Compare each team with its own past.
Watching one metric. Any one of the four can be improved at the expense of another. Look at all four together, every time.
How to start measuring
You do not need a dashboard to begin.
- Deployment frequency and lead time come from your CI/CD system and version control. Count last quarter's production deployments, and sample twenty changes for lead time.
- Change failure rate and time to restore come from incident records. If incidents are not linked to deployments, go through last quarter's by hand once.
Rough numbers are enough. The level matters less than the direction, and the direction shows up after two or three quarters.
One step further
DORA metrics measure how well you deliver. They do not say how much of the team is available to deliver at all. A team with excellent metrics and 35% of its time left after maintenance and interrupts will still miss its roadmap. The Engineering Capacity Calculator covers that half.
Check your team's DORA levels. Four questions, no sign-up.