DORA publishes five delivery metrics now, not four. The fifth is deployment rework rate: the share of deployments that were unplanned and happened because something broke in production [N1, N6]. If the engineering metrics dashboard you take to your board still says "the four keys," it is reporting against a model the source itself has moved past.
Key takeaways
DORA's five metrics, as currently published. DORA's guide sorts its five software delivery metrics into throughput and instability [N1].
- Change lead time — the time from commit to production [N2]. (throughput)
- Deployment frequency — how often the team deploys to production [N1]. (throughput)
- Failed deployment recovery time — how long it takes to recover from a failed deployment [N1]. (throughput)
- Change fail rate — the share of changes that fail in production [N1]. (instability)
- Deployment rework rate — unplanned deployments triggered by a production incident [N6]. (instability)
The Elite/High/Medium/Low performance tiers are no longer part of the model: the 2025 report replaced them with seven team profiles [N10].
Somebody above you wants a number for engineering performance, and most of the engineering metrics on offer have never been checked against reality.
DORA's current guide sorts its five metrics into throughput (change lead time, deployment frequency, failed deployment recovery time) and instability (change fail rate, deployment rework rate), and describes the shift from the original four keys to the five-metric model in its own words [N1]. Change lead time is still commit-to-production [N2]; deployment rework rate, the addition, counts unplanned deployments triggered by a production incident [N6].
The larger change is what happened underneath. The 2025 report dropped the Elite/High/Medium/Low performance tiers in favor of seven team profiles derived from a cluster analysis across nearly 5,000 technology professionals and more than 100 hours of qualitative data [N10]. Google Cloud's own framing for why: "Simple software delivery metrics alone aren't sufficient. They tell you what is happening but not why it's happening" [N10]. Neither the current guide nor DORA's Quick Check publishes numeric tier thresholds any more [N12]. A dashboard that colour-codes squads against "Elite" is grading them against a construct its authors retired.
That is the shape of the problem in miniature. Here is the test worth applying to any indicator on your report: is it a property of the change and its path through the system, or a property of the people and the plan? Almost everything that survives evidence is the first kind. Almost everything that fails is the second.
The number of people attached to a single change, how many modules it touches, and how big it is — in that order [V2.4]. The most useful study on delivery speed is old, narrow, and reaches a conclusion nobody quotes.
James Herbsleb and Audris Mockus published it in IEEE Transactions on Software Engineering in June 2003, using change-management records from two departments of a single company covering July 1997 to July 1999 [V2.2, V2.3]. Date it in your head before you use it. The headline is the part that travelled: distributed work items took about two and a half times as long to complete as comparable colocated ones [V2.1]. In Department A, 2,227 modification requests: five days single-site against 12.7 days when more than one site was involved, p < 0.001 [V2.2]. Department B replicated it on 4,974 requests, roughly seven days against 18 [V2.3].
That is where most citations stop. The paper doesn't. When the authors ranked what actually drove the interval, the ordering was "number of people, diffusion, and size" [V2.4]. And when they ran a multiple regression controlling for those variables, distribution stopped mattering: after taking all other variables into account, whether the project was distributed had no significant effect on interval [V2.5]. Their reading is blunt. Splitting work across sites slows it down "primarily because it requires the involvement of more people than comparable work accomplished all at one site" [V2.6].
Read that as a measurement instruction rather than a geography argument. The thing that predicted duration was headcount attached to a single change, plus how many modules it touched, plus how big it was. Headcount is the input every engineering plan is built around — see our developer hiring statistics for 2026 — and this result puts it directly on the critical path of a single change [V2.4]. Distribution was a proxy that dissolved under control. Every organization has proxies like that on its dashboard: a variable that correlates because it drags a real cause along behind it, and that stops explaining anything the moment you measure the cause directly.
One caution about this paper, because it has two halves and they are not interchangeable. Everything above comes from the instrumented change data. The paper also surveyed 92 people about delays, and there the finding was different in kind: cross-site delays happened at about the same rate as local ones, 1.9 per month against 2.1, but lasted 2.4 days against 0.9 [V2.7]. The frequency gap was not statistically significant; the duration gap was, at p < 0.02 [V2.8]. Those are self-reported durations. They are worth knowing and they should not be blended into the measured result.
The best-instrumented view of change size comes from Google, and the numbers are smaller than almost anyone guesses: a median change of 24 lines, drawing a median of one reviewer [V3.5, V3.7].
Sadowski and colleagues analyzed roughly nine million changes from more than 25,000 authors and reviewers between January 2014 and July 2016 [V3.1]. The median change modified 24 lines, and over 10% modified exactly one [V3.5]. More than a third touched a single file, and about 90% touched fewer than ten [V3.6]. The median reviewer count was one, with fewer than 25% of changes drawing more than a single reviewer [V3.7]. Over 80% of changes involved at most one round of resolving comments [V3.8]. Gousios and colleagues found the same silhouette across 291 open-source projects and 166,884 pull requests: most pull requests are under 20 lines and are merged or discarded in under a day [V4.1, V4.3].
Size then propagates into review. Google's measured split is that developers wait a median of under an hour for initial feedback on a small change and about five hours on a very large one [V3.3]. The broader claim that review quality degrades with size is real but needs careful attribution: the paper asserts it while citing prior work on declining useful comments and rising latency [N42], and the finding that developers feel size drives latency comes from a survey of Mozilla contributors [N45]. The directly measured Google result is the latency split. Google's operational response is on the record too: the size/quality correlation is acknowledged internally and developers are strongly encouraged to make small incremental changes, with exceptions for large deletions and automated refactoring [N43]. Where that review load includes machine-generated code, our note on testing AI-generated code covers the practices we apply.
Then the finding that inverts the intuition. Average comments per change rise with lines changed up to a peak of 12.5 comments at around 1,250 lines, and then fall, because changes bigger than that tend to be auto-generated code or bulk deletions [N44]. Past a certain size, a change does not attract more scrutiny. It attracts less. The 4,000-line pull request that sat in review for a week was not being examined that whole time.
We have written elsewhere about shrinking batches as a remedy. The point here is narrower: change size is one of the few things you can measure cheaply and precisely today.
Review and merge latency are the most quotable hard numbers available, because several large systems have published theirs. Google's median latency for the entire review process, across all code sizes, is under four hours [V3.2].
During the week, 70% of changes are committed less than 24 hours after being mailed out for initial review [V3.4]. The same paper lists comparison points from other organizations: 17.5 hours at AMD, 15.7 for Chrome OS, and 14.7, 19.8 and 18.9 hours across three Microsoft projects, with another study putting median time to approval at Microsoft at 24 hours [V3.9]. On the open-source side, 30% of pull requests merge in under an hour and 80% within 3.7 days [V4.2].
Those are reference points, not targets, and the same work explains why to be careful with them. Gousios and colleagues found merge time was influenced by the developer's previous track record, the size of the project, its test coverage and its openness to external contributions [V4.4]. In other words, project-level factors dominate the specific pull request. More usefully for anyone about to build a forecast on this: when they modelled merge time directly, no single feature dominated, at least six were needed, and the classifier reached only moderate accuracy, AUC 0.74 [V4.5].
That is the honest ceiling. Latency is a good diagnostic and a weak oracle. Worth reporting weekly, not worth promising a date on.
Every organization measures what it produced. Almost none measure what it had to produce twice.
Barry Boehm and Victor Basili put a number on it in IEEE Computer in January 2001: software projects spend about 40 to 50 percent of their effort on avoidable rework [N36]. Two companion findings from the same list matter as much. Rework is Pareto-distributed, with about 80 percent of avoidable rework coming from 20 percent of the defects [N37]. And when the authors looked at where process improvement actually paid, most of the effort savings from better process maturity, architecture and risk management came from reductions in avoidable rework [N38].
The same article deserves credit for something rarely quoted alongside it. It carries the famous claim that fixing a problem after delivery is often 100 times more expensive than fixing it during requirements and design, and then immediately revises it: for small, non-critical systems the cost-escalation factor is "more like 5:1 than 100:1" [N39]. The 100:1 number has been used to justify a great deal of front-loaded process. Its own source narrowed it a quarter of a century ago.
The modern instrumented version of rework is churn, and it comes with the sharpest lesson in this post. Nagappan and Ball measured code churn against defect density on Windows Server 2003: 44.97 million lines, 2,465 binaries [N41]. Absolute measures of churn were poor predictors of defect density. Their set of relative churn measures, normalized against component size and time, discriminated fault-prone from non-fault-prone binaries at 89.0 percent accuracy [N33, N41]. Same raw signal. One version tells you nothing; the other is the strongest quantified predictor in this post. The difference is a denominator.
For the current trend, GitClear's 2026 maintainability research (vendor research, from a company that sells a code-metrics product) reports two-week code churn up 15% against a 2022 baseline, drawn from 623 million analyzed changes between 2023 and 2026 [V5.1, V5.7]. We read that alongside the wider AI coding statistics for 2026 rather than on its own.
Story points, velocity, lines of code and commit counts — the metrics on your report that cannot support the weight placed on them [N27, N29, N33, N35]. Two of them fail in genuinely different ways, and the difference matters.
Story points have been studied, and they came out weak. The largest test compared 37,440 user stories across 37 agile open-source projects against recorded time. As reported in the paper's abstract, strong correlations existed for only 7% of projects, with medium correlations in 58% and low in 35%, and the authors concluded that story points might not be an accurate indicator of time [N27]. The machine-learning literature reinforces it from the other direction: a replication of state-of-the-art automated estimation found it beat a simple median baseline with statistical significance in only 8 of 42 cases [N28]; the best reported agreement from a comparative-learning approach is a Spearman correlation of 0.34 [N30]; and a 2026 retrieval-augmented attempt across 23 projects found no statistically significant differences in performance [N31].
Velocity is a different case. It has never been properly checked. A sweep of the published literature on story points returns work on predicting the story-point label using deep learning, graph networks, LLMs and retrieval — and nothing comparing team velocity against delivery outcomes [N29]. So the accurate sentence is this one: nobody has shown that velocity predicts anything, because as far as the published record goes, nobody has properly checked. That is not the same as saying velocity has been disproven. It hasn't. It has been used for two decades as a forecasting instrument without anyone publishing evidence that it forecasts.
Lines of code deserve a similar precision. The famous critique is Dijkstra's, from December 1988, and it is rhetoric rather than data: if we count lines of code, "we should not regard them as 'lines produced' but as 'lines spent'" [N32]. The measured case is narrower than it is usually made to sound. What Nagappan and Ball actually showed is that absolute measures like LOC and absolute churn are poor predictors of defect density [N33]. That is a claim about defects, not about value.
Commit counts fail on range before they fail on principle. SPACE names pull requests, commits and code reviews as prone to error from data gaps and measurement problems, and as blind to collaborative work like pairing [N19], and states that activity metrics should never be used in isolation to reward or penalise developers [N18]. The empirical problem is arithmetic: at Google, the median developer authors about three changes a week and 80% of authors make fewer than seven [N35]. A metric whose entire working range is three to seven cannot carry a performance conversation.
The frameworks people cite for these metrics are much more cautious than the dashboards built from them, and they say so explicitly.
DORA invokes Goodhart's law by name, warning that broad statements like "every application must deploy multiple times per day by year's end" increase the likelihood that teams will game the metrics [N7]. It says the metrics are meant to be applied at the application or service level [N9]. It says the goal is to improve your team's performance over time, "not to compete against other teams or organizations" [N8]. Three instructions on one page, and the standard leadership rollup violates all three.
SPACE, the framework people reach for when they want developer productivity metrics, is blunter still. Its central takeaway is that productivity cannot be reduced to a single dimension or metric [N17]. A good measure spans at least three dimensions [N20], and adding another activity metric doesn't count — if you already measure commits, adding pull requests and coding time gets you nothing, because those are all activity [N21]. At least one metric should be perceptual, such as survey data [N22]. It also describes the gaming mechanism concretely: rate a team only on story points and members optimise their own points at the expense of invisible work that matters to other developers, other teams, and future hires [N23].
None of these authors treat gaming as an edge case. They treat it as the default response to a single-number target. Microsoft's own current internal system, EngThrive, is designed on that assumption — its published design principles include choosing metrics so that "gaming" behavior aligns with genuine improvement [N51], and it is offered as a model for organizations trying to move beyond measuring activity toward improving outcomes [N52].
There is also a structural flaw worth knowing about. A May 2026 analysis points out that every DORA metric is a first-moment statistic or a simple ratio, so deployment frequency says nothing about the distributional shape of deployment timing: two teams with identical scores can be deploying on a metronomic cadence or in erratic bursts. Working from 120 weeks of Jira, GitHub and Firebase data, the authors' alternative measure separated platforms with identical DORA placements but different cadence regularity [N15]. An average tells you the middle. Predictability lives in the spread.
Take only what survived and the list is short: how many people a change needs, how big it is, how long it waits, and how much of it comes back.
People per change is the strongest single finding here, and nothing else on a standard dashboard captures it [V2.4, V2.5]. It is also the measure that lands closest to how you resource work, which is the ground our comparison of software development staffing models covers. Change size is cheap to instrument and there are real reference distributions to compare against [V3.5, V3.6]. Review and merge latency are benchmarkable against published figures from Google, AMD, Chrome OS and Microsoft, provided you treat them as diagnostics rather than forecasts [V3.2, V3.9, V4.5]. Rework belongs on the report, expressed as relative churn rather than absolute [N33, N41]. And per SPACE, none of these works alone: cover at least three dimensions, and make at least one of them perceptual, which in practice means asking your engineers something and putting the answer next to the telemetry [N20, N22].
One governance metric is worth deleting outright. DORA found no evidence supporting the hypothesis that a more formal, external review process was associated with lower change fail rates [N13], and argues that heavyweight external approvals hurt delivery performance because they slow the process down and push teams toward releasing larger batches less frequently, with more impact on production when they land [N14]. That is the mechanism, and it is the one place batch size belongs in a measurement conversation: your approval board is not reducing failures, it is enlarging the units you fail in.
At You-Source we instrument the change path first, because it is the part of engineering performance you can actually move in a quarter, and we would rather show a client a smaller number that means something. If that is the measurement discipline you want on your own team, it is how Dev on Demand works.
DORA's current guide publishes five metrics, not four: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate, sorted into throughput and instability [N1]. Change lead time is measured commit-to-production [N2], and deployment rework rate counts unplanned deployments triggered by a production incident [N6]. The Elite/High/Medium/Low performance tiers were dropped in the 2025 report in favor of seven team profiles [N10]. Neither the current guide nor DORA's Quick Check publishes numeric tier thresholds any more [N12].
Mostly not. The largest test compared 37,440 user stories across 37 agile open-source projects against recorded time, and found strong correlations for only 7% of projects, medium correlations in 58% and low in 35% [N27]. The authors concluded that story points might not be an accurate indicator of time [N27]. Automated estimation has not closed the gap either: a replication of state-of-the-art methods beat a simple median baseline with statistical significance in only 8 of 42 cases [N28].
Nobody has shown that velocity predicts anything, because as far as the published record goes, nobody has properly checked [N29]. A sweep of the published literature on story points returns work on predicting the story-point label using deep learning, graph networks, LLMs and retrieval, and nothing comparing team velocity against delivery outcomes [N29]. That is not the same as saying velocity has been disproven. It hasn't.
The number of people attached to a single change. Herbsleb and Mockus ranked the drivers of interval as "number of people, diffusion, and size" [V2.4], and once those variables were controlled for in a multiple regression, whether the project was distributed had no significant effect on interval [V2.5]. Their own reading is that splitting work across sites slows it down "primarily because it requires the involvement of more people than comparable work accomplished all at one site" [V2.6].
No. DORA states that the goal is to improve your team's performance over time, "not to compete against other teams or organizations" [N8], and that the metrics are meant to be applied at the application or service level [N9]. It also invokes Goodhart's law by name, warning that broad organization-wide targets increase the likelihood that teams will game the metrics [N7]. Engineering KPIs run as league tables produce exactly the behavior SPACE describes, where members optimise their own points at the expense of invisible work that matters to other developers, other teams, and future hires [N23].
