In this post
The four measures
- Deployment frequency: how often you deploy to production.
- Lead time for changes: how long a change takes from commit to production.
- Change failure rate: the share of deployments that cause a failure needing a fix.
- Time to restore service: how long it takes to recover from a failure.
What they tell you
Speed and stability tend to move together in strong teams, which is why small, frequent, well-tested changes work. The measures show where the pipeline is slow or fragile.
Using them well
- Measure per service or team to find bottlenecks, not to compare people.
- Look at trends, not single readings.
- Pair them with how the team feels about its work.
- Beware gaming: a number made into a target stops measuring what it did.
Improving them
Shorten feedback loops, automate tests and deployment, keep changes small and practise recovery. See speed and stability are not a trade-off.
Sources and further reading
- DORA. Software delivery performance metrics. dora.dev/guides/dora-metrics.
IICTP is a new independent credential and is not ISO/IEC 17024 accredited.