DORA Metrics and Beyond

The DORA research programme identified four metrics that together describe software delivery performance, and — more importantly — found that throughput and stability move together rather than trading off. Teams that deploy more frequently also recover faster and fail less often.

That finding is what makes these metrics useful: they give you a way to argue that speed and safety are the same investment, not competing ones.

The four metrics link

flowchart LR
    subgraph "Throughput"
    A[Deployment frequency]
    B[Lead time for change]
    end
    subgraph "Stability"
    C[Change failure rate]
    D[Failed deployment recovery time]
    end
    A & B & C & D --> E["These move together.<br/>Small batches make deployment<br/>frequent, failures rarer,<br/>and recovery faster."]

The mechanism behind the correlation is batch size. Small, frequent changes are easier to review, easier to test, easier to attribute when something breaks, and easier to revert. Every one of the four metrics improves as batch size falls.

Instrumenting them honestly link

Every metric here has a definitional trap, and picking the wrong definition produces numbers that look good and mean nothing.

Deployment frequency. Count deployments to production that reach users. Deployments to staging are not deployments. If you use feature flags, count both deployments and flag-enablement events, but keep them separate — they answer different questions.

Lead time for change. Measure from first commit on the branch, not from merge. Measuring from merge hides the review and rework queue, which is usually the largest component and the most actionable one.

flowchart LR
    A[First commit] -->|"coding"| B[PR opened]
    B -->|"review wait — often the largest slice"| C[Approved]
    C -->|"merge queue"| D[Merged]
    D -->|"pipeline"| E[Deployed to production]
    A -.->|"Lead time: measure this whole span"| E
    D -.->|"Not this — it hides the queue"| E

Change failure rate. Requires linking deployments to incidents, which is where most implementations get soft. The honest signals: an automatic rollback occurred, a hotfix deployment followed within a short window, or an incident record references the deployment. Deployments aborted by canary analysis count as failures — a caught failure is still a failure, and excluding them creates an incentive to weaken the canary.

Recovery time. Measure from detection, and separately track detection time itself, because a fast recovery on a failure discovered two days late is not a good outcome.

Where to get the data link

All four are derivable from systems you already have:

flowchart TD
    A[Version control<br/>commit timestamps] --> E[Metrics pipeline]
    B[CI/CD system<br/>deployment events, artifact digests] --> E
    C[Incident management<br/>declared incidents, timestamps] --> E
    D[Service catalogue<br/>ownership, tier] --> E
    E --> F["Per-service and per-team dashboards<br/>with trends, not single values"]

Two implementation notes that determine whether the result is trustworthy: automate the collection entirely — self-reported delivery metrics are uniformly optimistic — and key everything on the artifact digest, so a deployment can be traced to its exact commit without ambiguity.

How these get gamed link

Any metric used for evaluation will be optimised, including in ways that make the underlying reality worse.

The structural defence is to use these metrics for improvement, not for comparison between teams. A team maintaining a legacy monolith and a team running a greenfield service have incomparable baselines. Comparing them produces gaming; comparing each team to its own trend produces improvement.

The metrics DORA does not cover link

The four are about delivery. They say nothing about whether the delivered thing was worth building, or whether the people building it can keep doing so. A complete picture adds:

Unplanned work as a share of capacity is the most useful single addition. A team spending 60% of its time reacting has no capacity to improve anything, and that fact explains stalled metrics better than any delivery number does.

Using the numbers well link

• Report trends, not point values. “Lead time fell from 3 days to 8 hours over two quarters” is information; “lead time is 8 hours” is trivia.
• Segment by service tier. A tier-1 payments service and an internal admin tool should not have the same profile, and averaging them hides both.
• Connect the metric to a specific constraint. If lead time is dominated by review wait, the fix is reviewer capacity or smaller changes — not a faster pipeline.
• Re-baseline after structural change. A migration or reorganisation invalidates comparison with earlier periods; say so rather than explaining a discontinuity every month.

Adoption checklist link

• All four metrics are collected automatically from pipeline and incident data.
• Lead time is measured from first commit, not from merge.
• Aborted canary rollouts count as change failures.
• Detection time is tracked separately from recovery time.
• Metrics are keyed to artifact digests for unambiguous traceability.
• Counter-signals are tracked alongside each metric to detect gaming.
• Teams are compared to their own trend, not to each other.
• Unplanned work share and developer experience are measured alongside delivery.