DORA Metrics: Measuring Software Delivery Performance

DORA & Delivery Metrics

Engineering leaders are asked to quantify their teams, and most of the obvious answers are actively harmful. Lines of code, commit counts, story points, and PR throughput all share the same defect: they measure individual activity, they're trivially gamed, and optimizing them makes teams worse — collaboration drops, work is split artificially, and review quality declines.

The DORA metrics avoid this by measuring the system rather than the people in it. They come from the DevOps Research and Assessment program, which surveyed tens of thousands of professionals over more than a decade, and their central finding is genuinely useful: throughput and stability are not a tradeoff. Teams that deploy more frequently also have lower failure rates and recover faster, because small changes are easier to review, easier to roll back, and easier to diagnose.

The four metrics tell you where a delivery pipeline is slow or fragile. What they don't tell you is whether the team is building the right thing — which is a separate question and, usually, the more important one.

TL;DR

Four metrics: deployment frequency, lead time for changes, change failure rate, time to restore.
Two are throughput, two are stability — and elite teams score well on both. They aren't a tradeoff.
They measure the delivery system, not individuals. Applied to people, they're gamed immediately.
Small batches are the mechanism: frequent small deploys are safer than infrequent large ones.
Lead time is where the bottleneck usually is — and it's usually waiting, not working.
A fifth metric, reliability, was added to reflect operational outcomes.
These say nothing about whether you're building the right thing. Pair them with product outcomes.
Improve one at a time, and only after finding the actual constraint.

The Four Metrics

Performance levels

Treat the bands as orientation, not as a target. A team going from monthly to weekly deploys has made a much larger improvement than one going from twice a day to three times a day, and the second may not be worth pursuing at all.

Quick Example

Instrumenting the metrics from data you already have:

The data sources are things most teams already have: a deployment record (or CI/CD pipeline history), git, and an incident tracker. The hardest part is usually agreeing on definitions — what counts as a deploy, and what counts as a failure — not collecting the numbers.

Core Concepts

Why small batches work

This is why throughput and stability correlate rather than trade off, and it's the single most useful idea in the whole framework. Teams that deploy rarely usually do so because deploying is scary, and it's scary because they deploy rarely.

Lead time is mostly waiting

When teams try to reduce lead time, the instinct is to make CI faster. The measurement almost always shows the time is in queues: waiting for review, waiting for a release window, waiting for approval, waiting for a manual QA pass. Instrument each stage separately before optimizing, or you'll optimize the 40 minutes and leave the 3.6 days.

Defining a failure

The change failure rate is the metric teams argue about most, so define it explicitly and write it down:

Whatever definition you pick, apply it consistently. A change failure rate that quietly narrows its definition over time shows improvement that isn't real, and everyone eventually notices.

The fifth metric

Reliability was added to the framework to capture operational outcomes rather than delivery mechanics: availability, latency, and performance against SLOs. It's a corrective for the fact that the four delivery metrics can all look excellent on a service that's slow and unreliable — you're shipping frequently and safely to a system users find frustrating.

What DORA doesn't measure

A team with elite DORA metrics shipping features nobody uses is a team efficiently building the wrong thing. Pair delivery metrics with product outcome metrics and with a developer experience signal (SPACE framework, or simply asking people). DORA answers "is our pipeline healthy?" — an important question and not the only one.

Best Practices

Measure teams and services, never individuals

The moment a metric is attached to a person's review, it's gamed — PRs get split to raise counts, risky-but-valuable work gets avoided, and people stop helping each other because helping doesn't show up in their numbers. DORA works because it describes a system nobody individually controls.

Instrument what you already have

Deployment records, git history, and incident tickets cover all four. Don't buy a platform before you've computed them from existing data — the exercise of defining "deploy" and "failure" for your context is most of the value, and it's not something a tool does for you.

Use medians and percentiles

One PR that sat for three weeks makes a mean lead time meaningless. Report p50 and p90: the median describes the typical experience and p90 shows the tail, which is where the frustrating cases live.

Find the constraint before optimizing

Break lead time into stages and find where the time actually goes. Speeding up CI when the bottleneck is a two-day review queue is measurable effort with no measurable result. See CI/CD.

Improve one metric at a time

Deployment frequency is usually the right first target because improving it tends to drag the others along — smaller batches improve review quality, failure diagnosis, and rollback confidence simultaneously.

Track trend, not absolute position

"Are we better than last quarter?" is a useful question. "Are we elite?" mostly isn't — the bands come from a survey across wildly different contexts, and a regulated system with a mandated change window will never look like a consumer web app. Compare yourself to yourself.

Pair with a developer experience signal

A team can improve DORA numbers by working longer hours, which is unsustainable and invisible in the metrics. A quarterly developer experience survey — how easy is it to ship, how much friction do you hit, how do you feel about on-call — catches what the delivery numbers can't.

Publish the definitions

Write down what counts as a deploy, a failure, and an incident, and where each number comes from. Metrics whose definitions live in one person's head are metrics that quietly drift and lose credibility the first time someone questions them.

Common Mistakes

Applying them to individuals

Making them targets rather than signals

Goodhart's law is not a theoretical concern here — it's the observed outcome every time these are made into targets.

Optimizing the wrong stage

An inconsistent failure definition

Treating throughput and stability as a tradeoff

Using DORA as the only lens

FAQ

Are the elite benchmarks realistic for us?

Sometimes not, and that's fine. Regulated environments with mandated change windows, embedded systems with physical devices, and enterprise software with customer-scheduled upgrades all have hard constraints on deploy frequency. Measure your own trend. A team that moved from quarterly to monthly releases has improved enormously, regardless of what band that puts them in.

How do we count a deploy behind a feature flag?

Count the deployment when code reaches production, and treat the flag flip as a separate release event. Trunk-based development with flags is one of the strongest ways to improve these metrics honestly, because it decouples deploying from releasing — code ships continuously in small batches while features are enabled on their own schedule. See Feature Flags.

Do we need a tool for this?

No, and starting without one is better. All four metrics are computable from deployment records, git, and an incident tracker with a modest amount of SQL. Platforms (LinearB, Swarmia, Sleuth, DX) save integration work and add richer breakdowns, and they're worth considering once you're actively using the numbers — not as a way to start.

What about SPACE?

SPACE is a complementary framework covering Satisfaction, Performance, Activity, Communication, and Efficiency — deliberately broader than DORA and including how developers feel about their work. The two pair well: DORA measures delivery outcomes, SPACE measures the developer experience producing them. Neither alone gives a complete picture.

How often should we review them?

Monthly for the trend, quarterly for anything structural. Weekly is noise — small teams have enough variance that week-to-week movement means nothing, and reacting to it produces churn. Annotate the chart when something changes (a reorganization, a new pipeline, a definition change) so trends can be read in context.

Won't this just create pressure to ship faster?

It can, if leadership treats the numbers as targets — which is the failure mode to guard against. Framed correctly they do the opposite: they justify investment in CI/CD, test automation, and tooling by showing where the delivery system is slow, and they demonstrate that reliability work and speed are the same investment rather than competing ones. Presenting them as "here's what's slowing us down" rather than "here's your score" makes most of the difference.