DORA Metrics Explained: How to Measure Engineering Team Performance

Ask ten engineering managers how they measure team performance and you will get ten different answers — story points per sprint, lines of code, features shipped, PR count. Most of these metrics have serious problems: they can be gamed, they measure activity rather than outcomes, and they offer no way to compare across teams or organizations.

DORA metrics are different. They emerged from seven years of rigorous research across tens of thousands of organizations and engineers, and they are the closest thing the software industry has to a universal benchmark for delivery performance. They measure what actually matters: how fast you ship, how reliably you ship, and how quickly you recover when things go wrong.

This guide explains exactly what the four core DORA metrics are, how to calculate each one, where your team likely stands against industry benchmarks, and — most importantly — how to improve without gaming the numbers.

What Are DORA Metrics?

DORA stands for DevOps Research and Assessment. The program was founded by Dr. Nicole Forsgren, Jez Humble, and Gene Kim — the same people who co-authored the book Accelerate: The Science of Lean Software and DevOps (2018). Google acquired the DORA research team in 2018 and has continued publishing the annual State of DevOps Report ever since.

The research asked a fundamental question: what does high-performing software delivery actually look like, and can we measure it objectively? Starting in 2014, the team surveyed over 33,000 professionals across industries, company sizes, and geographies. The result was a statistically validated set of capabilities and metrics that predict both delivery performance and broader organizational outcomes — including profitability, market share, and employee satisfaction.

"Our data shows that elite software delivery performance is achievable by any organization — large or small, in any industry — and that it predicts better organizational outcomes." — Nicole Forsgren, Accelerate

The research identified four core metrics that capture everything meaningful about software delivery. They split cleanly into two categories:

In 2021, the State of DevOps Report added a fifth metric — Reliability — which measures whether your service is meeting its SLOs (Service Level Objectives). While the four original metrics measure how well you deliver, Reliability measures what users actually experience after delivery. We'll focus on the four core metrics in this guide, as they are the most universally applicable and actionable.

The Four Core DORA Metrics Explained

1. Deployment Frequency (DF)

Deployment Frequency measures how often your team successfully releases code to production. It is the simplest DORA metric to understand and often the most revealing — teams that ship infrequently usually ship infrequently for a reason: large batch sizes, manual gates, fear of breaking things, or missing automation.

How to calculate it: Count production deployments in a given period. DF = COUNT(production_deployments) / days_in_period. Report it as deployments per day or per week depending on your current frequency.

The research finding that surprises most teams: elite performers deploy multiple times per day while experiencing lower failure rates than teams that deploy monthly. The reason is batch size — more frequent deploys mean smaller, easier-to-review, easier-to-rollback changes. Infrequent, large releases concentrate risk.

2. Lead Time for Changes (LTC)

Lead Time for Changes measures the end-to-end time from when a developer's first commit reaches the repository to when that code is serving production traffic. This is a measure of your entire delivery pipeline — code review speed, CI pipeline duration, testing time, deployment gates, and release processes all contribute to it.

How to calculate it: For each deployment, find the timestamp of the earliest commit included in it, and subtract from the deployment timestamp. Average across all deployments in the period. LTC = avg(deploy_time − first_commit_time).

Lead time is a diagnostic metric. When it's long, it tells you something is slow — but not what. Is it code review bottleneck? A flaky test suite that runs for 45 minutes? A manual sign-off gate? A weekly release window? Breaking down lead time into sub-stages (time-in-review, CI duration, time-waiting-for-deploy) reveals where to focus.

3. Change Failure Rate (CFR)

Change Failure Rate is the percentage of deployments that result in a production failure — an incident, rollback, hotfix, or degraded service state. It is the primary quality signal in the DORA framework and measures your team's ability to deliver changes that are stable and reliable.

How to calculate it: CFR = (failed_deployments / total_deployments) × 100. A "failed deployment" is one that required a rollback, an emergency hotfix, or triggered a P1/P2 incident within a defined window (usually 24–48 hours of the deploy).

The counterintuitive finding from the research: teams with the highest deployment frequency tend to have the lowest change failure rates. Small, frequent changes are individually lower-risk than large, infrequent batches. When you ship 20 changes in one deploy, diagnosing which one caused the outage is significantly harder than a deploy with two changes.

4. Mean Time to Restore (MTTR)

Mean Time to Restore — sometimes called Mean Time to Recovery — measures how quickly your team detects and resolves production incidents. It is a measure of operational resilience: how good are your monitoring and alerting, how practiced is your incident response, how clear are your runbooks, and how empowered is your on-call rotation to take decisive action?

How to calculate it: MTTR = avg(incident_resolved_time − incident_detected_time). Use your incident management system (PagerDuty, Opsgenie, Incident.io) as the source of truth — detection time is when the alert fired or the incident was opened, resolution time is when the service returned to normal SLO.

MTTR depends heavily on three capabilities: observability (can you tell something is wrong, and where?), incident process (can you coordinate response quickly?), and reversibility (can you roll back or feature-flag the bad change immediately?). Teams with mature MTTR invest heavily in all three.

DORA Performance Tiers: Where Does Your Team Stand?

The State of DevOps Report classifies organizations into four performance tiers based on their DORA metric values. These tiers are derived from cluster analysis of the survey data — teams naturally cluster into these groups rather than being placed into arbitrary buckets.

The gap between Elite and Low performers is staggering. According to the 2023 State of DevOps Report, Elite performers deploy 208× more frequently than Low performers, have 106× faster lead time, and restore service 2,604× faster. These are not incremental differences — they represent fundamentally different ways of working.

Most organizations sit in the Medium tier. Moving from Medium to High is achievable in 6–12 months with focused investment. Moving from High to Elite typically takes 1–2 years and requires cultural shifts alongside technical ones — particularly around ownership, trust, and deployment automation.

Elite performance is not about working harder. It is about removing the friction that prevents teams from moving fast safely — smaller batches, better automation, and trust in the team's ability to detect and fix problems quickly.

How to Measure Each DORA Metric

You don't need a dedicated observability platform to start measuring DORA metrics. Many teams begin with a simple spreadsheet and graduate to automated tooling once the habits are in place.

Tools and data sources

The four maturity stages of DORA measurement

1. Ad hoc: Someone counts deployments manually at the end of the month. No formal tracking. This is where most teams start — and that's fine.
2. Tracked: A shared spreadsheet or Notion doc where deployments and incidents are logged. Requires discipline but gives you trend data within weeks.
3. Automated: CI/CD system pushes deployment events to a dashboard automatically. Incident data flows from your on-call tool. Metrics update in real time.
4. Optimized: DORA metrics are surfaced in sprint reviews and retrospectives. The team runs experiments specifically targeting metric improvement. Metrics influence architecture and process decisions.

How to Improve Your DORA Metrics

Each DORA metric responds to specific interventions. The good news is that improvements compound: faster lead time enables more frequent deployments, which produce smaller changesets, which reduce failure rates, which increase team confidence to deploy again. The virtuous cycle is real — once you break through the fear of frequent deploys, everything gets easier.

When planning improvements, work on one metric at a time. The most common mistake is running simultaneous initiatives across all four metrics — teams lose focus and nothing improves decisively. Choose the metric that most limits your team right now, run a 90-day experiment targeting it specifically, and review the result in your sprint retrospectives before moving on.

Common Mistakes When Implementing DORA Metrics

Mistake 1: Using DORA metrics to compare teams

This is the most damaging misuse of the framework. DORA metrics are designed for teams to measure their own improvement over time. Comparing Team A's deployment frequency to Team B's ignores context completely: Team A might deploy a critical payments service with strict change-management requirements, while Team B deploys a marketing microservice with zero compliance burden. Cross-team comparison creates pressure to game numbers rather than improve genuinely.

Mistake 2: Only measuring the easy metrics

Deployment Frequency is trivial to instrument from CI/CD logs. Change Failure Rate and MTTR require correlating deployment and incident data, which is harder. Teams that skip CFR and MTTR get a dangerously incomplete picture — a team can deploy 20 times per day with a 40% failure rate and look impressive on one metric while being operationally catastrophic on the others.

Mistake 3: Gaming the numbers

Gaming is surprisingly common once DORA metrics are tied to performance reviews. Common forms: labelling rollbacks as "planned" to avoid the CFR counter; closing incidents before service is actually stable; splitting one PR into multiple micro-commits to inflate deployment count. The remedy is to automate data collection from objective, non-human sources — CI/CD systems, incident management tools — and to be explicit that these metrics are for improvement, not evaluation.

Mistake 4: Ignoring the fifth metric — Reliability

Shipping fast and shipping reliably matters — but if you're burning through your error budget and users are experiencing failures, deployment speed is an empty victory. Make sure your SLO health is visible alongside the four DORA metrics. A team hitting Elite on all four throughput and stability metrics but missing their availability SLO every month hasn't actually won anything.

DORA Metrics vs Other Engineering Metrics

DORA metrics don't replace other team-level metrics — they complement them. Here's how they relate to the measurements you're likely already tracking:

Velocity (story points per sprint) is an internal planning aid — it tells you how much work a team can pull into a sprint, not how quickly that work reaches users or how reliably it works. Velocity is a predictability metric. DORA metrics are delivery performance metrics. You need both, but DORA tells you far more about team health.

Cycle time (in a Kanban context) covers the full journey from "in progress" to "done." Lead Time for Changes is narrower — it starts at the first commit, not at ticket creation, and ends at production, not at the pull request being merged. Agile teams often track cycle time alongside DORA Lead Time to get a complete picture.

Code coverage percentage is a quality proxy, not a delivery performance indicator. High test coverage does not guarantee low change failure rate — it depends entirely on what the tests cover and how well they simulate production conditions. Coverage is useful for identifying untested surface area; DORA CFR tells you whether your actual delivery process is failing.

SPACE metrics (Satisfaction, Performance, Activity, Communication, Efficiency) — introduced by GitHub and Microsoft Research in 2021 — focus on individual developer experience and productivity. DORA focuses on team-level delivery outcomes. They are complementary: SPACE tells you how engineers feel; DORA tells you what they actually ship.

If you're choosing where to start, begin with DORA. It has the strongest research backing, the clearest benchmarks, and the most actionable lever points. Once you have DORA instrumented and stable, layer in SPACE surveys to understand the human factors driving your metric trends.

For engineering leaders comparing tool options, understanding your DORA metrics should inform your choice of project management software — platforms that give you sprint visibility, deployment integrations, and incident tracking in one place make DORA data collection significantly easier.