What is DORA Metrics?

#What the five metrics measure

Change lead time measures how long it takes a change to move from commit to production. Deployment frequency measures how often an application or service is deployed. Failed-deployment recovery time measures how long it takes to recover from a deployment that fails and requires immediate intervention.

Change fail rate is the proportion of deployments that require immediate intervention, such as a rollback or hotfix. Deployment rework rate is the proportion of deployments that are unplanned and occur in response to a production incident. DORA currently groups change lead time, deployment frequency, and failed-deployment recovery time under throughput, and change fail rate and deployment rework rate under instability.

#Why DORA metrics matter

A recurring finding in the research is that speed and stability tend to move together rather than trading off. Teams that deploy frequently often recover faster and fail less often, because small frequent changes are easier to verify, diagnose, and reverse.

• Balanced view: throughput and instability are measured together, so neither can be optimized in isolation without the other showing it.
• Actionable: each metric points at a specific part of the delivery pipeline.
• Comparable: the five metrics give teams a common vocabulary for discussing software-delivery performance.
• Evidence-based: the metrics come from research across many organizations rather than from intuition.

#Limits and misuse

A common misuse is treating the metrics as targets for individual teams to hit. Deployment frequency in particular can be gamed by splitting one change across five deploys, which improves the number and nothing else. The metrics should be interpreted together and in the context of a specific application or service.

They also describe the delivery process rather than the outcome. A team can deploy hourly with strong recovery times and build software nobody wants. DORA measures how well you ship, not whether what you ship is worth shipping.

#DORA metrics vs SRE metrics

SRE metrics such as SLIs, SLOs, and error budgets describe the service as users experience it: is it fast enough, correct enough, available enough.

DORA metrics describe the engineering system that produces the service: how quickly changes flow and how often they destabilize production. They answer different questions and are complementary. A team can have strong DORA metrics and miss its SLOs, which can mean it ships fast and the architecture cannot support the reliability target. The reverse, strong SLOs with weak DORA metrics, can mean reliability is being bought with slow, painful releases.

#Key takeaways

• The five current DORA metrics are change lead time, deployment frequency, failed-deployment recovery time, change fail rate, and deployment rework rate.
• DORA groups the metrics into software-delivery throughput and instability.
• The metrics are most useful when tracked over time for one application or service; comparisons across unrelated teams can be misleading.
• DORA metrics describe the delivery system, while SLIs and SLOs describe service behavior and user experience.

#Frequently asked

Which DORA metric should a team improve first?

There is no universal first metric. Start with the largest constraint in the delivery process and examine all five metrics together so that improving one measure does not create instability elsewhere.

Do these metrics apply to teams that deploy infrequently by necessity?

The metrics still describe the delivery system accurately. Regulated or embedded contexts may have legitimate constraints, but the measures remain a fair description of how changes flow.

Can DORA metrics be used for performance reviews?

Tying them to individual evaluation tends to make them useless, because the metric gets optimized directly rather than through the improvements it was meant to indicate.

#Sources

• DORA: software-delivery performance metrics