Skip to content
matthewcm.dev

    ↑ ↓ move · ↵ open · tab scopeopen graph →

    DORA Metrics

    Four measures of software delivery, two for throughput and two for stability. In high-performing teams they improve together, so speed and safety aren't a trade-off.

    Growingtended planted 2 min read
    On this page

    The DORA (DevOps Research and Assessment) programme spent years studying what separates high-performing software teams from the rest. It boiled delivery performance down to four metrics.

    The four keys

    MetricTypeQuestion
    Deployment frequencyThroughputHow often do we ship to production?
    Lead time for changesThroughputHow long from commit to running in production?
    Change failure rateStabilityWhat share of deployments cause a failure that needs a fix or rollback?
    Time to restore serviceStabilityWhen something breaks, how quickly do we recover?

    Later State of DevOps reports add reliability, meaning whether you’re meeting your availability and performance goals. That links straight to SLOs.

    The finding that matters

    You’d expect speed and stability to trade off: ship faster, break more. The research says the opposite. Elite teams are better at both. Small, frequent changes are easier to test, easier to review and easier to roll back. Speed and safety come from the same practices.

    Using them well

    • Measure teams and systems, never individuals. Turn DORA metrics into personal targets and Goodhart’s Law takes over: people game the number and stop improving the system.
    • Measure before and after a change. Splitting a slow pipeline, adding a platform capability, introducing trunk-based development: each should move a specific metric. Check rather than trust feelings.
    • Read them together. Deployment frequency rising while change failure rate also rises isn’t progress.

    An example

    A team whose pull-request checks take most of an hour will batch changes to avoid waiting. Batching raises lead time and makes each deployment riskier. Splitting checks into fast PR checks and heavier merge checks (see Shift Left Testing) should show up as lower lead time first, and over time as a lower change failure rate.

    Where they fit

    DORA metrics are Observability for the delivery process, and the scorecard for an Internal Developer Platform: if the platform is working, these numbers move.

    • #dora
    • #devops
    • #delivery-metrics
    • #platform-engineering
    • Blue-Green DeploymentSeed
      …akes it a direct lever on recovery time (SLA vs SLO vs SLI) and on how fast you recover from a failed change (DORA Metrics).
    • Books That Shaped How I BuildGrowing
      …on system and designs the paths work actually takes, so nobody has to be a hero. That's what Golden Paths and DORA Metrics are for, and why You Can't Serve Two Masters.
    • Deloads Are Tech-Debt SprintsGrowing
      Those are the signals a coach looks for too: stalled progress, sloppy form, aches that don't settle. I'd watch the first two through DORA Metrics and the rest through conversations.
    • Digital Culture Is Built from HabitsGrowing
      …visible. Faster lead time, fewer incidents, less waiting on other teams — and measured, so people can see it. DORA Metrics are a reasonable start.
    • Goodhart's LawSeed
      …estions, not to hand out rewards. Read several together, so improving one at the expense of another shows up. DORA Metrics are a good example: brilliant for learning about delivery, dangerous as targets.
    • Growing a Platform: Breadth, Depth and Gear ShiftingGrowing
      …they wait, batch up work and suffer painful merges, even though smaller releases would mean fewer conflicts. DORA Metrics make this visible, as long as nobody turns them into targets (Goodhart's Law).
    • Internal Developer PlatformGrowing
      …me and deployment frequency should improve as friction drops, without change failure rate rising. That's what DORA Metrics measure. Adoption, and what developers say in surveys, are the product metrics.

    ↪ Links to (5)