Skip to content

CONCEPT Cited by 1 source

DORA metrics

DORA metrics — four software-delivery performance indicators established by the DevOps Research and Assessment program led by Dr. Nicole Forsgren, with Jez Humble and Gene Kim, and codified in the 2018 book Accelerate: Building and Scaling High Performing Technology Organizations. The metrics are extracted from the annual State of DevOps survey (N in the thousands) and are the closest thing the industry has to an empirically-grounded framework for software delivery performance.

The four metrics

Metric What it measures Elite-performer target
Deployment frequency How often code reaches production On-demand (multiple times per day)
Lead time for changes Time from commit to deployed in prod < 1 day
Change fail rate Fraction of deploys causing incidents 0–15%
Mean time to restore (MTTR) Time to recover from a production failure < 1 hour

The first two measure throughput, the second two measure stability. The DORA-research punchline: throughput and stability are positively correlated — organizations that deploy more often also recover faster and fail less often. The common intuition ("move slow to stay safe") is empirically backwards.

The external-approval result

The DORA finding most directly cited in the Swedbank / change-controls post:

"External approvals were negatively correlated with lead time, deployment frequency, and restore time, and had no correlation with change fail rate."

Translated: approval by a CAB or external change manager (concepts/external-approval-ineffectiveness) makes three of four DORA metrics worse and doesn't improve the fourth. "Worse than having no change approval process at all."

What moves DORA metrics positively

Per Accelerate, the capabilities most associated with elite DORA performance (partial list):

  • Trunk-based development with small batch sizes.
  • Continuous integration with fast builds.
  • Continuous delivery with automated deployment pipelines.
  • Automated testing (unit, integration, acceptance).
  • Small, frequent releases — directly corroborated by the UK FCA's parallel finding in regulated financial services: "firms that deployed smaller, more frequent releases had higher change success rates than those with longer release cycles."
  • Staged rollouts — canary / blue-green / feature-flagged deploys to reduce blast radius.
  • Fast rollback — the capability that directly lowers MTTR.
  • Peer review (versus external approval).
  • Monitoring in production — see concepts/observability and patterns/runtime-change-detection.

Why MTTR often dominates incident cost

The DORA framing surfaces an operational truth underappreciated in traditional change management: outage cost is largely set by MTTR, not by outage frequency. A system that fails 10× as often but recovers 100× faster is net-better. This is why patterns optimized for restore time — fast rollback, feature-flag-gated bad releases, runtime monitoring of the production state — outperform patterns optimized for prevention (CABs, service windows, freeze periods).

Limitations

  • DORA is industry-heterogeneous. Sample skews toward tech-forward orgs; applicability to heavily regulated / legacy sectors is less settled (though the UK FCA's 1M-change study broadly corroborates the trend).
  • DORA measures delivery, not code quality. An org can hit elite DORA numbers shipping garbage that happens to ship and roll back fast.
  • "Change fail rate" is a definition problem. What counts as a failure (any alert? a user-visible outage? an SLA breach?) varies.
  • The survey is self-reported. Recency bias and aspirational reporting are well-documented confounds.

Seen in

Last updated · 319 distilled / 1,201 read