DORA Metrics and Delivery Performance: What the Research Shows

The DORA program (DevOps Research and Assessment) is among the largest long-running efforts to quantify software delivery. Its annual State of DevOps reports began in 2014, and the book Accelerate by Nicole Forsgren, Jez Humble and Gene Kim (2018) laid out the statistical method and the headline findings. The metrics have since become a default vocabulary for engineering leadership.

What the research says

The core claim is that a small set of measures of delivery performance cluster together and predict organizational outcomes. The four key metrics are deployment frequency, lead time for changes, change failure rate, and time to restore service. The first two capture throughput, the latter two capture stability. A notable finding is that throughput and stability were not a trade-off in the survey data: teams that deployed more often also tended to recover faster and fail less often. Later reports added a reliability dimension and have revised the metric set and the way performance groups are defined, so older cluster labels such as elite or low should be read against the specific report year.

The research also identified technical and cultural capabilities associated with better performance, including continuous integration, trunk-based development, loosely coupled architecture, test automation and a generative organizational culture.

What practitioners see

Teams that adopt the metrics usually find the data is harder to collect than expected. What counts as a deployment when you have feature flags? When does lead time start: first commit, pull request opened, or ticket created? Change failure rate depends on how a team defines failure and whether incidents are reliably linked back to changes. Two teams reporting the same number may be measuring different things.

Practitioners also report the predictable Goodhart effect. When a metric becomes a target, people split deployments into trivial pieces, reclassify incidents, or ship empty releases. Dashboards that rank teams against each other tend to produce this behavior faster than dashboards used for a team's own reflection.

Another common observation is that the metrics diagnose rather than prescribe. A long lead time tells you something is slow, but not whether the cause is code review queues, flaky tests, change approval boards or an architecture that forces coordinated releases.

Gaps and cautions

• The underlying data is largely self-reported survey responses, which carries the usual risks of recall bias and respondents interpreting questions differently.
• The studies are mostly cross-sectional, so they show association and use statistical modeling to argue for direction of effect, but they are not controlled experiments.
• Survey respondents are self-selected and skew toward organizations already engaged with DevOps practice.
• The benchmarks come from many contexts at once. Regulated embedded software and a consumer web service face different constraints, and a single comparison table hides that.
• Metrics from one team's pipeline do not capture product value. Shipping quickly does not mean shipping the right thing.

How to apply it

Start by writing down precise definitions for your own context and keep them stable, so trends are meaningful. Use the metrics as a conversation starter inside a team, and compare a team to its own past rather than to a published tier. Pair throughput and stability metrics so neither is optimized alone, and add qualitative signals such as developer experience surveys or incident reviews.

When a metric looks poor, investigate the system: map the delivery value stream, find the longest wait, and run one improvement experiment at a time. Treat the capabilities listed in the research as hypotheses to test in your environment, not as a checklist guaranteed to move the numbers.

Finally, resist using the metrics for individual performance evaluation. They describe a delivery system, not a person.

Key takeaways

• DORA's four key metrics pair throughput with stability, and the data showed them improving together rather than trading off.
• The evidence is survey-based and correlational, so treat it as strong guidance rather than proof of causation.
• Definitions matter more than the numbers: agree on what counts as a deployment, a failure and a start time.
• Metrics used as targets get gamed; use them for team learning, not ranking.
• The metrics tell you where to look, not what to fix, so pair them with value stream analysis and qualitative feedback.