DORA Metrics
DORA metrics measure software delivery as a system, not individual heroics. The common set is deployment frequency, lead time for changes, change failure rate, and time to restore service. Modern DORA work also emphasizes reliability and organizational outcomes because delivery speed without dependable service is not success.
The Four Core Measures
Deployment frequency asks how often value can reach users. Lead time for changes asks how long committed work takes to run in production. Change failure rate asks what fraction of deployments cause degraded service or require remediation. Time to restore service asks how quickly the team can recover after failure.
These metrics are useful because they create productive tension. If a team deploys more often and the failure rate rises sharply, the delivery system is losing control. If failure rate is low only because deployment is rare, the organization may be hiding risk in large batches.
Misuse
DORA metrics should not become personal productivity scores. They are system signals. A high lead time may reflect approval queues, unstable tests, unclear ownership, fragile architecture, or overloaded reviewers. The metric points to investigation; it does not replace it.
Interpreting Metrics Together
The four measures become powerful when interpreted as a set. Deployment frequency and lead time describe flow. Change failure rate and time to restore service describe stability. A delivery system is improving when flow improves without stability collapse, or when stability improves without freezing change. The tension is the point.
For example, a team may reduce deployment frequency while performing a difficult migration. That is not automatically failure. The question is whether the slower rate is an intentional investment with visible risk reduction, or whether it is a symptom of fear and large-batch release habits. Metrics require context, but context should explain the data rather than excuse it.
Data Quality
DORA measurement can be distorted by poor event definitions. A deployment should mean a production change to a service or user-facing system, not every CI run. Lead time should be measured consistently, often from commit or merge to production. A change failure should include incidents, rollbacks, emergency fixes, or degraded service caused by a change. Restore time should measure user-impact recovery, not the moment a ticket was closed.
Teams should document these definitions. Otherwise, metric changes may reflect instrumentation changes rather than delivery improvement.
Example Investigation
Suppose lead time rises from two days to eight days. The next step is not a slogan about speed. Break the time into coding, review, CI, staging, approval, deployment, and verification. If staging consumes five days because shared test data is unreliable, the improvement target is environment design. If review consumes five days because two experts are overloaded, the target is knowledge distribution and review policy.
Study Task
Create a DORA scorecard for one service. Include each metric, its definition, source system, known blind spots, and one improvement hypothesis. Treat the scorecard as a conversation starter, not a ranking table.