Measuring Delivery: DORA Metrics
How do you know whether a team is actually good at delivering software? Years of research distilled the answer to four numbers, the DORA metrics, which together balance speed and stability — and reliably predict high-performing teams.
What makes them powerful is the balance: they measure how fast a team ships and how safely, at the same time. Chasing one without the other is the classic mistake these metrics were designed to expose.
Think of a car's combined stats: not just how fast it goes, but how rarely it crashes and how quickly it recovers when it does. A great team, like a great car, is fast and reliable — and you need both numbers to know it.
The Four Metrics
The four DORA metrics fall into two pairs — two about speed, two about stability.
| Metric | Measures | Type |
|---|---|---|
| Deployment frequency | How often you ship to production | Speed |
| Lead time for changes | How long from code written to live | Speed |
| Change failure rate | How often a change causes a problem | Stability |
| Time to restore service | How fast you recover from an incident | Stability |
Speed vs Stability
The first two metrics measure speed — how often and how quickly you deliver. The last two measure stability — how rarely you break things and how fast you recover. The surprising, well-evidenced finding is that great teams excel at both at once. Speed and stability are not a tradeoff you have to choose between; the practices in this course (testing, CI, small changes, automation) improve both together.
Why These Four
Why these particular numbers? Because they resist being gamed in the way naive metrics don't. Measuring "lines of code" or "number of commits" rewards busywork — you can look productive by writing more, worse code. The DORA four measure outcomes: did working software reach users, often and safely? It's much harder to fake delivering value than to fake activity.
Using Them Well
One caution: use DORA metrics to improve the system, not to rank or punish individuals. The moment a metric becomes a target to beat, people optimize the number instead of the real goal. Used right, the four metrics start a conversation — "our recovery time is slow; what would help?" — that makes the whole team better. Used as a scoreboard, they backfire.
The Cadence team tracks all four. They deploy daily (good deployment frequency), changes reach production within hours (short lead time), few of their deploys cause incidents (low change failure rate), and when one does, they recover in minutes (fast time to restore). Those four numbers are concrete evidence that the practices from this whole course — testing, CI, small reversible releases — are actually working for them.
- "Speed and stability are a tradeoff." DORA's key finding is that great teams achieve both at once — the same practices (testing, CI, small changes) improve speed and stability together.
- "Measure productivity by lines of code or commits." Those reward busywork and are easily gamed. DORA measures outcomes — working software delivered often and safely — which is far harder to fake.
- "Use the metrics to rank individuals." They measure the system, not people. As a personal scoreboard they get gamed and backfire; as a team conversation-starter they drive real improvement.
- DORA is the industry's most respected way to talk about delivery performance — recognizing the four metrics lets you join those conversations.
- They tie every practice in this course to a measurable outcome: testing, CI, small releases, and automation all move these four numbers.
- Understanding that speed and stability rise together, and that metrics measure systems not people, are two genuinely important lessons.
Knowledge Check
What do the four DORA metrics measure together?
- Both the speed and the stability of how a team delivers software
- How many lines of code each individual developer writes in a day
- How visually appealing the finished application ends up looking to users
- The total number of developers that the team currently employs
Which is one of the four DORA metrics?
- Deployment frequency — how often you ship to production
- The total number of meetings that the team holds every single week
- How many different programming languages the codebase happens to use
- The total number of lines of code written across the whole project
What is DORA's surprising finding about speed and stability?
- Great teams achieve both at once; they are not a tradeoff to choose between
- You must always sacrifice stability in order to gain more delivery speed
- Stability only ever matters for the very largest teams and never for smaller ones
- That the speed of a team can never actually be measured at all
Why measure outcomes like DORA rather than "lines of code"?
- Lines of code rewards busywork and is easily gamed; outcomes are harder to fake
- Because counting the lines of code is technically impossible to do at all
- Because longer code always runs much faster than shorter code ever does
- Because measuring lines of code is actually completely against the law in most places
You got correct