G · DiagnosisExternally proven

DORA Delivery Diagnostic

Captures a software organisation's delivery capability on a few hard numbers: how long a change takes from version control to production, how often you deploy, how often a deployment forces immediate intervention, and how quickly service is restored afterwards. Throughput and stability are read as a pair, never on their own. Measurement applies per service, not as a comparison between teams.

When you need this method

Claims about delivery capability almost always rest on impression. Engineering believes it is fast, the business believes it is slow, and neither side has a number. Where artificial intelligence enters development, the gap widens: what is visible is that more code gets written, what stays invisible is whether more of it reaches production and holds there. Without a baseline you can neither prove nor refute two quarters later that the investment paid off.

Approach

  1. 1Fix the unit of analysis. You measure one application or service, not the company as a whole and not one team against another.
  2. 2Collect the numbers: lead time for a change from version control to production, deployment frequency, recovery time after a failed deployment, share of deployments requiring immediate intervention, share of unplanned rework following incidents.
  3. 3Pull the numbers from version control and deployment tooling rather than from self-assessment. Surveys yield too few data points to reveal a trend over weeks.
  4. 4Read throughput and stability together. A gain in throughput that worsens failure rate or recovery time is not an improvement, it moves the cost downstream.
  5. 5Record a baseline before any significant change to the delivery chain, explicitly including the broad rollout of AI tooling, and measure again after several weeks.
  6. 6Name exactly one bottleneck and work on it, usually automated testing, the approval path, or feedback speed, instead of pushing on every number at once.

Typical application

A typical B2B SaaS with roughly seventy engineers rolls out AI assistance across the board and measures success by the number of accepted suggestions. Two quarters in, engineering reports that work feels noticeably faster, while sales complains about slipped commitments. The diagnostic collects the five numbers for the main service from version control and deployment tooling. Deployment frequency and lead time have genuinely improved. At the same time the share of deployments requiring immediate intervention has risen sharply and recovery time has grown longer. The bottleneck therefore is not writing code but an automated test suite sized for the previous rate of change. The team pauses further tool rollout, extends test coverage at the points where things break, and measures again after a quarter.

Limits and counter-indications

The numbers describe the delivery pipe, not the value of what is delivered. A team can ship the wrong thing quickly and stably. Used as a target or as a comparison between teams the measurement does damage, because deployment frequency is easily flattered by splitting deployments and failure rate by reclassifying incidents. Teams that release manually and quarterly generate too few data points to support a conclusion. Outside software delivery the diagnostic does not carry, for instance in consulting or hardware. And the findings on artificial intelligence come from cross-sectional self-reported surveys: they show associations, not causes, and the direction of the throughput finding has already reversed once between two survey years. Your own measurement replaces the industry number here, it is not validated by it.

How to measure impact

Keep a per-service baseline of the five numbers and always read throughput and stability as a pair. Only a change that improves lead time or deployment frequency without worsening failure rate, rework rate, and recovery time counts as progress.

Related methods

Tools for this

Sources

  1. 1.Forsgren, Rothenberger, Humble, Thatcher, Smith: A Taxonomy of Software Delivery Performance Profiles: Investigating the Effects of DevOps Practices, AMCIS 2020 (opens in a new tab) · Association for Information Systems, AIS Electronic Library (AMCIS 2020 Proceedings, Systems Analysis and Design) · 2020 · academic and scholarly literature · supports the underlying mechanismCarries the core of the diagnostic: delivery performance is composed of throughput measures (release frequency, lead time to delivery) and a stability measure (mean time to restore). In a sample of 7,522 practitioners a hierarchical cluster analysis yields three distinguishable performance profiles, with throughput and stability moving in tandem rather than against each other. Limit: cross-sectional self-report from a voluntary sample, no causal claim and no time series per team.
  2. 2.Sallin, Kropp, Anslow, Quilty, Meier: Measuring Software Delivery Performance Using the Four Key Metrics of DevOps, XP 2021 (opens in a new tab) · 22nd International Conference on Agile Software Development (XP 2021), Volltext offen über ZHAW digitalcollection, CC BY 4.0 · 2021 · academic and scholarly literature · describes the methodCarries the measurement procedure: deployment frequency, lead time for change, time to restore service, and change failure rate can be derived automatically from version control and deployment data. The authors note that the usual measurement is manual and survey based and therefore yields only few data points, and they build and trial a prototype for automated collection. Limit: the trial rests on a single application case, and there is no effectiveness evidence for the actions derived from the numbers.
  3. 3.DORA: Software delivery performance metrics (Guide) (opens in a new tab) · DORA (dora.dev), Google Cloud · 2026 (abgerufen) · practitioner source · provides the contextProvides the current definitions and application rules from the research group itself. The set now covers five measures rather than four, since alongside change fail rate it also captures the share of unplanned rework following incidents. It states explicitly that the measurement is applied per application or service and not as a comparison between teams. Limit: guidance from the publisher of the metrics, not independent evidence and no effectiveness measurement.
  4. 4.DORA: Balancing AI tensions, Moving from AI adoption to effective SDLC use (State of AI-assisted Software Development 2025) (opens in a new tab) · DORA (dora.dev), Google Cloud · 2025 · practitioner source · provides benchmark figuresCarries the AI angle of the diagnostic. In the 2025 survey, higher AI adoption is associated with both higher delivery throughput and higher delivery instability. 90 percent of respondents use AI at work, more than 80 percent believe it has made them more productive, and 30 percent have little or no trust in the code it generates. The authors read AI as an amplifier of existing strengths and weaknesses rather than a fix for structural problems. Limit: associations from a cross-sectional self-report survey, no causality.
  5. 5.Google Cloud: Announcing the 2025 DORA Report (opens in a new tab) · Google Cloud Blog · 2025 · practitioner source · limits the methodServes as a caution against adopting industry figures wholesale. The survey rests on nearly 5,000 practitioners and more than 100 hours of interviews. The relationship between AI adoption and delivery throughput was negative in the previous year and is positive in 2025, while the relationship with delivery stability stays negative in both years. The direction of the throughput finding is therefore not stable across years, and the industry number does not replace your own measurement. Limit: an announcement by the publisher, without reported effect sizes.

Origin: Forsgren et al. / DORA

← Back to the catalog

Work through this method with an AI

ClaudeChatGPTPerplexity