DORA metrics

Measurement before claims

Early transformation work can feel successful before the data supports that conclusion. Teams may be happier and releases may feel smoother, but a board technology committee needs evidence. The Tier-1 bank's DevSecOps transformation treated measurement as part of the work from the start.

DORA metrics provided a common language. Before their adoption, every team had its own definition of "fast" and "stable." One team measured deployment frequency by counting production releases; another counted deployments to staging. One team measured lead time from the moment a developer started coding; another measured it from the moment a ticket was created. These inconsistencies made it impossible to benchmark, compare, or identify systemic bottlenecks. The organization standardized on the DORA definitions from Forsgren, Humble, and Kim's "Accelerate" research, instrumented every pipeline to emit metrics automatically, and built dashboards that gave every team and every executive a consistent, real time view of delivery performance. Within six months, the data was driving decisions. Teams that were struggling could see where they were struggling. Teams that were excelling could articulate exactly what practices were driving their performance. The transformation stopped being a mandate from leadership and started being a data-informed competition among teams to improve.

The DORA measures

DORA metrics measure software delivery throughput and stability. The research was led by Nicole Forsgren, Jez Humble, and Gene Kim and validated across tens of thousands of organisations. The four measures are:

• Deployment Frequency: how often new code is deployed to production.
• Lead Time for Changes: the time it takes for a code change to go from commit to production.
• Change Failure Rate: the percentage of changes that result in a failure in production.
• Mean Time to Restore (MTTR): the average time it takes to restore service after a failure.

The Accelerate research found that high-performing organisations deploy more frequently, fail less often, and restore service faster. Speed and stability can improve together when teams invest in the same underlying delivery practices.

DORA performance profiles

The annual State of DevOps Reports, published by Google's DORA team, categorize organizations into performance clusters. As of the 2023 and 2024 reports, these clusters are:

Metric	Elite	High	Medium	Low
Deployment Frequency	On-demand (multiple times per day)	Between once per day and once per week	Between once per week and once per month	Between once per month and once every six months
Lead Time for Changes	Less than one hour	Between one day and one week	Between one week and one month	Between one month and six months
Change Failure Rate	0-5%	5-10%	10-15%	16-30%+
MTTR	Less than one hour	Less than one day	Between one day and one week	More than one week

When measurement began at the bank, most teams fell in the Low to Medium range. Within eighteen months of the golden path rollout, over sixty percent of teams had moved to High, and three teams, all on the golden path with fully automated security scanning, reached Elite. The correlation between golden path adoption and DORA metric improvement was the designed outcome.

The DORA framework continues to evolve. The 2025 edition, titled the State of AI-Assisted Software Development Report, expands the research programme considerably. It introduces Rework Rate as the fifth core metric: how often teams must deploy unplanned fixes or patches to correct user-facing defects. It also restructures the measurement framework into three throughput metrics (deployment frequency, lead time, rework rate) and two instability metrics (change failure rate and failed deployment recovery time, the renamed MTTR). The biggest change is that the report replaces the previous four-tier performance model (Elite, High, Medium, Low) with seven team archetypes identified through cluster analysis of throughput, instability, and team well-being measures: Foundational Challenges (teams in survival mode with significant process gaps), Legacy Bottleneck (constantly reacting to unstable systems), Constrained by Process (consumed by inefficient workflows), High Impact, Low Cadence (quality work, slow delivery), Stable and Methodical (deliberate, high quality), Pragmatic Performers (impressive speed, functional environments), and Harmonious High-Achievers (virtuous cycle of sustainable excellence). Each archetype experiences AI adoption differently, which the report argues demands tailored intervention strategies rather than one-size-fits-all guidance. Organisations reading their DORA data now need to interpret it against these archetypes rather than a simple tier ranking.

The 2026 agentic software research adds a second measurement layer for teams using AI agents in delivery. DORA remains the outcome scoreboard, but agent-native telemetry explains why those outcomes move. The useful additions are:

Agent Metric	What It Measures	DORA Link
Retrieval Precision	Whether the agent found the right files, ADRs, tests, incidents, and policies before acting	Lead time, change failure rate
Trajectory Review Rate	Percentage of high-risk AI-generated changes with preserved and reviewed tool-use traces	Change failure rate
Memory Supersession Rate	How often stale agent memory is replaced, expired, or corrected	Rework rate, change failure rate
AI-Serving SLO Attainment	Latency, timeout, cache, and fallback health of the LLM platform used by delivery workflows	Lead time, MTTR
Human Override Rate	How often accountable humans reject, amend, or roll back agent recommendations	Rework rate, change failure rate

These metrics complement DORA rather than replace it. They act as diagnostic lenses for AI-assisted teams, the same way lead-time decomposition explains where classic delivery pipelines are stuck.

Trajectory Review Rate is only measurable if the trajectory was preserved in the first place. Claude Code sessions are resumable and replayable (--resume, and session-log inspection more generally), and teams running the AI-DLC v2 workflow on top of Claude Code get this as a first-class feature: /aidlc-replay reconstructs what a session actually did, and its 82-event audit trail gives Trajectory Review Rate a real data source rather than an aspiration (see AI-powered SDLC with Claude Code). A team that can't answer "what did the agent read and run before it made this change" cannot report this metric honestly, only guess at it.

DORA metrics in AI and DevSecOps

DORA metrics show whether AI and DevSecOps changes improve delivery throughput and stability. They provide an outcome measure for changes to tools, controls, and team practices.

In financial services specifically, DORA metrics serve a dual purpose: they measure delivery performance and they provide evidence of operational risk management. Regulators increasingly expect banks to demonstrate that they can deploy changes reliably and recover from failures quickly. DORA metrics, when instrumented properly, provide exactly this evidence.

Deployment frequency

Deployment Frequency measures how often new code is deployed to production. High deployment frequency indicates a mature and efficient software delivery process. In AI and DevSecOps practices, frequent deployments enable teams to quickly iterate on improvements and deliver new features to users more rapidly.

The research consistently shows that higher deployment frequency correlates with lower risk, not higher risk. This is counterintuitive to many executives in regulated industries, where the instinct is to deploy less frequently to reduce risk. The data tells the opposite story: organizations that deploy infrequently accumulate large batches of changes that are harder to test, harder to debug when they fail, and harder to roll back. Frequent, small deployments are safer deployments.

At the bank, this evidence was presented to the board risk committee, earning support for increasing deployment frequency. The research was backed up with internal data: teams that deployed weekly had a change failure rate of three percent; teams that deployed monthly had a change failure rate of fourteen percent. The data was unambiguous.

Lead time for changes

Lead Time for Changes measures the time it takes for a code change to go from commit to production. Short lead times indicate an efficient development process. In AI and DevSecOps practices, reducing lead time for changes allows teams to respond faster to new data, changing requirements, and emerging threats.

Lead time decomposition is where the real diagnostic value lies. At the bank, the pipeline was instrumented to measure five distinct segments of lead time:

1. Coding time: from first commit to pull request creation.
2. Review time: from pull request creation to approval.
3. Security scan time: time spent in automated security scanning stages.
4. Build and test time: time in CI build and test execution.
5. Deployment time: from merge to production deployment completion.

This decomposition revealed that security scanning, which many teams blamed for slow pipelines, accounted for less than eight percent of total lead time. The actual bottleneck was review time: pull requests were sitting in review queues for an average of two days. This data driven insight redirected improvement efforts from optimizing scan performance (which would have yielded marginal gains) to improving review practices (which yielded substantial gains).

Change failure rate

Change Failure Rate measures the percentage of changes that result in a failure in production. Low change failure rates indicate a stable and reliable software delivery process. In AI and DevSecOps practices, monitoring and reducing change failure rates helps ensure that updates do not negatively impact production systems.

At the bank, the standard DORA definition of change failure was extended to include security failures: deployments that introduced a vulnerability detected post-deployment, configurations that violated compliance policies, or changes that triggered a security incident. This expanded definition aligned DORA metrics with the security governance framework and gave us a single metric that captured both operational and security reliability.

The 2024 State of DevOps Report found that testing quality and deployment maturity affect the relationship between deployment frequency and change failure rate. The bank's internal data showed the same pattern: teams with stronger functional and security test suites had lower change failure rates at every deployment frequency.

Mean time to restore

Mean Time to Restore (MTTR) measures the average time it takes to restore service after a failure. Low MTTR indicates a resilient and responsive software delivery process. In AI and DevSecOps practices, minimizing MTTR ensures that any issues in production are resolved quickly, reducing downtime and maintaining service reliability.

MTTR is the metric that most directly reflects an organization's operational resilience. In banking, where service availability is both a customer expectation and a regulatory requirement, MTTR is scrutinized at the highest levels. At the bank, MTTR was tracked separately for four categories:

1. Functional failures: application bugs that impacted user experience.
2. Infrastructure failures: platform or infrastructure issues.
3. Security incidents: vulnerabilities or breaches detected in production.
4. Compliance violations: changes that violated regulatory controls.

Each category had different MTTR targets and different escalation paths. Security incidents had the most aggressive MTTR targets (under thirty minutes for critical severity) and triggered automatic incident response playbooks that included isolation, forensic evidence preservation, and regulatory notification assessment.

The "Accelerate" research demonstrates that MTTR is more important than preventing all failures. Failures are inevitable in complex systems, so what matters is how quickly you can detect, respond, and recover. This philosophy informed the entire approach to resilience engineering at the bank.

Implementing DORA metrics at scale

Implementing DORA metrics across a large organization requires more than dashboards. It requires standardized instrumentation, consistent definitions, and a governance model that uses the data without weaponizing it.

Instrumentation

At the bank, DORA metrics were instrumented at the pipeline level, not the team level. Every golden path pipeline emitted standardized events to a central metrics platform:

• Deployment events: timestamp, service identifier, environment, deployer, commit hash.
• Change events: commit timestamp, merge timestamp, deployment timestamp (enabling lead time calculation).
• Failure events: incident timestamp, severity, category, resolution timestamp (enabling MTTR and CFR calculation).

This instrumentation was automatic for teams on the golden path and required minimal configuration for teams with custom pipelines. The data flowed into dashboards accessible to everyone, from individual contributors to the CTO.

Using metrics without weaponising them

The "Accelerate" research is explicit about this: DORA metrics must be used to improve, not to punish. The moment teams believe that metrics will be used against them, they will game the metrics, suppress incident reporting, and optimize for appearances rather than outcomes. At the bank, this principle was enforced through several mechanisms:

• Metrics were reported at the team level, never at the individual level.
• Teams set their own improvement targets in consultation with their engineering managers.
• Cross-team comparisons were presented as anonymized quartile distributions, not league tables.
• Blameless post-incident reviews were mandatory, and findings were shared across the organization as learning opportunities.

This approach built trust in the metrics program and ensured that the data drove genuine improvement rather than compliance theater.

Examples in AI and DevSecOps

1. Deployment frequency: by increasing the frequency of model deployments, teams can quickly iterate on model improvements and deliver new features to users more rapidly. For example, a team might aim to deploy new model versions weekly instead of monthly. At the bank, the ML model serving teams increased deployment frequency from monthly to weekly after adopting the golden path, with automated model validation and shadow deployment stages that caught regressions before they reached production traffic.

2. Lead time for changes: reducing the lead time for changes allows teams to respond faster to new data and changing requirements. For instance, automating the data pipeline and model training process can significantly reduce the time it takes to deploy updated models. Mean lead time across the organization dropped from twenty-three days to four days within the first year, with the primary improvement coming from automated security scanning (eliminating the six-week manual review) and streamlined review processes.

3. Change failure rate: monitoring and reducing the change failure rate helps ensure that model updates do not negatively impact production systems. Implementing robust testing and validation processes can help catch issues before they reach production. The organization-wide change failure rate dropped from eleven percent to four percent, with security-related failures dropping from three percent to under one percent.

4. Mean time to restore (MTTR): minimizing MTTR ensures that any issues in production are resolved quickly, reducing downtime and maintaining service reliability. For example, setting up automated rollback mechanisms can help restore service quickly in case of a failure. Automated canary analysis and instant rollback reduced the P1 MTTR from four hours to eighteen minutes.

References

1. Forsgren, N., Humble, J., and Kim, G. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press, 2018.

2. DORA State of DevOps Report 2023. Google Cloud, 2023. Available at: https://dora.dev/research/2023/dora-report/

3. DORA State of DevOps Report 2024. Google Cloud, 2024. Available at: https://dora.dev/research/2024/dora-report/

4. Kim, G., Humble, J., Debois, P., and Willis, J. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press, 2016.

5. Kim, G., Behr, K., and Spafford, G. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. IT Revolution Press, 2013.

6. Forsgren, N., Smith, D., Humble, J., and Frazelle, J. "DORA 2024 Accelerate State of DevOps Report." Google Cloud, 2024.

7. Humble, J. and Farley, D. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley, 2010.

8. DORA State of AI-Assisted Software Development Report 2025. Google Cloud, 2025. Available at: https://dora.dev/research/2025/dora-report/

9. arXiv. (2026). "Agentic Software: How AI Agents Are Restructuring the Software Paradigm." arXiv:2606.05608. https://arxiv.org/abs/2606.05608

10. arXiv. (2026). "CORE-Bench." arXiv:2606.11864. https://arxiv.org/abs/2606.11864

11. arXiv. (2026). "Agent Memory: Characterization and System Implications of Stateful Long-Horizon Workloads." arXiv:2606.06448. https://arxiv.org/abs/2606.06448