Technology & Data · 5 min read
DORA Metrics Explained: Measuring Software Delivery Performance
The DORA metrics are the most widely used way to measure software delivery performance. They are simple to describe, surprisingly easy to misuse, and very useful when applied with care.
For years, software teams struggled to measure their performance in a way that was meaningful and fair. Lines of code, story points and hours logged were easy to count but said little about whether teams were delivering value reliably. The DORA metrics changed that conversation.
They come from a long-running research programme known as DORA, short for DevOps Research and Assessment. The research, popularised in the 2018 book Accelerate by Nicole Forsgren, Jez Humble and Gene Kim, found that a small set of delivery measures was linked to better organisational performance. DORA later became part of Google Cloud and continues to publish annual research.
This article explains the core metrics, how to measure them, and how to use them without falling into the common traps.
The four key metrics
The DORA research groups software delivery performance into two themes: throughput (how quickly changes flow) and stability (how reliably they work).
1. Deployment frequency
How often your team successfully releases changes to production.
High-performing teams deploy small changes frequently, often on demand. Teams that release large batches monthly or quarterly tend to find each release riskier, harder to test and harder to fix.
How to measure: count production deployments per service over a period, from your deployment pipeline or release records.
2. Lead time for changes
How long it takes for a code change to go from being committed to running in production.
Short lead times mean feedback arrives quickly and fixes can be shipped fast. Long lead times usually point to manual testing, approval queues or infrequent release windows.
How to measure: for each change, take the time between commit and successful deployment, and look at the median over a period.
3. Change failure rate
The proportion of deployments that cause a failure in production requiring remediation, such as a rollback, hotfix or patch.
This balances the throughput metrics. Deploying frequently is only valuable if changes work.
How to measure: divide the number of deployments that led to an incident or rollback by the total number of deployments.
4. Time to restore service
How long it takes to recover when a change or incident causes a failure in production. In more recent DORA research this is framed around recovering from failed deployments specifically.
Failures will happen. What matters is how quickly the team can detect them and recover.
How to measure: for each production incident, take the time from detection to recovery, and look at the median.
Beyond the four
DORA's research has evolved over time. Later reports added a focus on operational performance and reliability, and have refined how stability is measured. The four metrics above remain the core, but they are best seen as indicators of a healthy delivery system rather than the whole picture.
Why these metrics work
The DORA metrics have three useful properties:
- They measure outcomes, not activity. They describe how the delivery system performs, not how busy people are.
- They balance each other. Pushing deployment frequency up while ignoring change failure rate shows up quickly. Speed and stability are measured together.
- They point to causes. Long lead times lead naturally to questions about testing, approvals and architecture. High failure rates lead to questions about test coverage and release practices.
A key finding of the research is that speed and stability are not a trade-off. Teams that deploy more often, in smaller batches, tend to have fewer failures and recover faster, because each change is smaller and easier to understand.
Common mistakes
Using the metrics to rank teams
The fastest way to ruin a metric is to tie it to targets or rankings. Teams will find ways to deploy more often without delivering more value, or to classify failures so they do not count. Use the metrics for teams to understand and improve their own delivery, not to compare teams with different products and constraints.
Measuring without context
A team maintaining a regulated, safety-critical system will have different patterns from a team running a marketing website. Compare a team with its own past performance first.
Ignoring how the numbers are produced
Metrics are only as good as the data. Agree clear definitions: what counts as a deployment, a failure and a recovery. Automate collection from your pipeline and incident tools wherever possible, so the numbers are consistent and nobody has to compile them by hand.
Forgetting the user
The DORA metrics measure delivery performance, not whether you are building the right things. Pair them with measures of user value, such as adoption, satisfaction or business outcomes.
How to get started
- Pick one or two teams and agree definitions for each metric.
- Collect a baseline for the last three months, automatically if possible.
- Discuss the results with the team, asking what is slowing changes down or causing failures.
- Choose one improvement, such as automating a manual test step, and measure again.
- Expand gradually to other teams once the definitions and data are trusted.
Where the metrics fit in DevOps maturity
The DORA metrics describe the results of good practice. Getting better at them depends on the practices underneath: continuous integration, automated testing, deployment automation, infrastructure as code, monitoring, and a culture where development and operations share responsibility.
The DevOps / CI-CD assessment looks at those practices across six areas: culture and collaboration, continuous integration, continuous delivery and deployment, infrastructure as code, monitoring and feedback, and security in the pipeline. For the engineering practices that come earlier, such as code quality, testing and documentation, the Software Development assessment is a useful companion.
Frequently asked questions
What does DORA stand for?
DevOps Research and Assessment, the research programme behind the metrics. It is now part of Google Cloud.
Are the DORA metrics only for large technology companies?
No. Any team that releases software can use them, from a small internal team to a large product organisation. The aim is improvement over time, not hitting a particular benchmark.
What is a good deployment frequency?
It depends on the product and context. Rather than chasing an external benchmark, aim to make each release smaller and more routine, and watch whether change failure rate and recovery time improve alongside it.