How quietly DORA became not four, but five metrics (Category Productivity)
For a long time, DevOps Research & Assesment, or simply DORA, has had a long history. 4 metrics on which the clustering of teams on different levels of elite was built. These metrics were about delivery speed and stability. Delivery speed: deployment frequency and lead time for changes MTTR/time to restore service and change fail rate This story can be read in more detail in my Reading "Accelerate")
From January 2026 It was the year Dora 5 software delivery performance metrics, which website Also divided into two categories.
1ная Throughput - system bandwidth
- Change lead time - time from commit to successful deployment in sales Deployment Frequency – How often you roll out changes Failed deployment recovery time - how quickly you recover after a bad deploitation
2️⃣ Instability Change Fail Rate: The percentage of depletions requiring immediate intervention Deployment rework rate - the proportion of unplanned depletions that had to be done due to a product incident / defect
The question arises. What's changed? Compared to the old model and why was it done? There were two changes and both are important.
- MTTR/Time to Restore Service 2023 It was redefined as failed deployment recovery time. DORA explains this directly by the fact that the old definition mixed problems caused by a change in the code with external incidents like outage in the data center. The new formulation is better statistically "adhesive" to delivery-metrics.
- In 2024 DORA has added a new fifth metric, the deployment rework rate. Their logic was this: the change fail rate catches immediate issues well after release, but does not reflect the volume of subsequent unplanned rework. Therefore, DORA decided to measure rework as a separate part of instability.
If we talk about the use of metrics, then the question arises: and now the classification will go according to 5 Metrics? And the answer is yes, but there are nuances... the DORA guys separately emphasize that the number of clusters is not fixed and is not manually set. In the FAQ, they write that clusters they have emergent from the data: 2018 usually 3s 2018 along 2021 - 4in 2022 again 3in 2023 and 2024 - again 4. That is, a fixed "always" 4 The class of teams should no longer be perceived.
If you think about it, what does that mean for conventional tech executives? (||Who does not evaporate according to methodology and metrics||)? It seems that DORA has become better at distinguishing between two different kinds of problems: Immediate file after release → change fail rate Delayed unplanned remodeling due to sales problems → deployment rework rate This is useful because the team can look “normal” on rollback/hotfix immediately after release, but still systematically sink into unplanned rework in a day or two. In the old 4In the metric model it was seen worse; in the new model it was seen better. This is the main substantive update of the model.
Separately, it should be said that 5 The metric has been used in DORA before, namely 2021/2022 In the years when there was an operational metric reliability, but it was not about software delivery performance, but the current great five is delivery metrics.
P.S. The @ai4sdlc chat yesterday discussed metrics and there was a suggestion just to use DORA. As a result, I decided to write this post to show that even DORA is not easy to calculate, but also the very understanding of drift metrics over time:)
#DevEx #Metrics #DevOps #Engineering #Software #Management #Leadership