DORA Metrics Communication — Engineering Metrics Language Exercises

1 / 5

During an engineering all-hands, the VP of Engineering says: "We track all four DORA metrics." What are the four DORA metrics, and which two are velocity metrics versus stability metrics?

DORA (DevOps Research and Assessment) metrics are the industry-standard framework for measuring engineering delivery performance, validated by research across thousands of organisations.

Metric	Category	Measures
Deployment Frequency	Velocity	How often code is deployed to production
Lead Time for Changes	Velocity	Time from commit to running in production
Mean Time to Restore (MTTR)	Stability	Time to restore service after an incident
Change Failure Rate	Stability	% of deployments causing a service degradation

DORA performance tiers (2023 State of DevOps Report):

Tier	Deploy Freq	Lead Time	MTTR	CFR
Elite	Multiple/day	<1 hour	<1 hour	<5%
High	1/day–1/week	1 day	<1 day	5–10%
Medium	1/week–1/month	1 week–1 month	1 day–1 week	10–15%
Low	<1/month	1–6 months	>1 week	>15%

Key vocabulary:
• DORA — DevOps Research and Assessment; research org founded by Nicole Forsgren, Jez Humble, Gene Kim
• Velocity metric — measures how fast value is delivered to production
• Stability metric — measures how reliably the system operates after changes

2 / 5

An engineering team reports: "Our lead time for changes is 18 days." What does lead time for changes mean in DORA vocabulary, and which performance tier does 18 days place this team in?

Lead time for changes is one of the most meaningful engineering velocity metrics — it captures the entire software delivery pipeline from code commit to production.

What the clock measures exactly:
Start: the moment a developer commits code to the main branch (or opens a PR)
End: the moment that same code is serving production traffic

What contributes to long lead times:

Stage	Common bottleneck
Code review	Long queue; reviewers not available; large PRs
CI pipeline	Slow tests; flaky gates; manual approvals
Staging/QA	Manual testing queues; environment availability
Deployment approval	Change advisory boards; scheduled deploy windows

18 days = medium performer tier:
This means code written by a developer takes over two weeks to reach users, significantly limiting the team's ability to respond to feedback, fix production bugs quickly, and iterate on features. Improvements: trunk-based development, smaller PRs, automated testing, removing manual deployment gates.

Key vocabulary:
• Lead time for changes — time from code commit to running in production
• Trunk-based development — all developers commit to a single main branch; reduces merge delays
• Deployment pipeline — the automated sequence from code commit to production; bottlenecks here directly inflate lead time

3 / 5

A postmortem document states: "MTTR for this incident was 4 hours 23 minutes." What does MTTR measure, how is it calculated, and which DORA tier does 4h23m represent?

MTTR (Mean Time to Restore) is the primary measure of how well a team recovers from production failures — a critical indicator of operational maturity and system resilience.

Precise definition:
MTTR = Sum of all restoration times ÷ Number of incidents
Restoration time = Time from detection (alert triggered) to service restored (back to SLA-compliant behaviour)

Important distinction — MTTR vs related terms:

Term	Measures
MTTR (Restore)	Detection → service restored to normal
MTTD (Detect)	Failure begins → alert triggers
MTTF (Failure)	Last repair → next failure
MTBF (Between Failures)	Average time between successive failures

4h23m context:
DORA "medium" tier for MTTR: 1 day–1 week. 4h23m is actually near the high tier boundary (<1 day = high performer). Elite teams restore in under 1 hour, typically through automated rollback and feature flag disabling.

How elite teams achieve sub-1-hour MTTR:
• Automated rollback triggered by error rate spike (e.g. Argo Rollouts canary analysis)
• Feature flags for instant disabling of new functionality
• Runbooks with step-by-step recovery procedures
• Well-practiced incident response (regular game days)

Key vocabulary:
• MTTR — Mean Time to Restore; detection to full service recovery
• Rollback — automated reversal of a deployment to the previous known-good state
• Feature flag — a runtime switch enabling/disabling functionality without redeployment

4 / 5

A VP of Engineering asks: "Our change failure rate is 18%. What does that mean in context?" How should this metric be explained using DORA vocabulary?

Change failure rate (CFR) is the stability counterpart to deployment frequency — it tells you whether the velocity you are achieving comes at the cost of reliability.

Precise definition:
CFR = (Number of deployments causing a degraded service or requiring remediation) ÷ (Total number of deployments) × 100

What "counts" as a failure:
• Emergency hotfix deployed within hours of a release
• Rollback of a deployment due to errors or user complaints
• Incident declared as a result of a deployment
• Production patch deployed to correct a regression

DORA performance tiers for CFR:

Tier	CFR	Meaning
Elite	<5%	Fewer than 1 in 20 deployments causes issues
High	5–10%	1 in 10–20 deployments causes issues
Medium	10–15%	1 in 7–10 deployments causes issues
Low	>15%	More than 1 in 7 deployments causes issues

18% = low performer; remediation actions:
• Strengthen automated testing (increase branch coverage, add integration tests)
• Implement canary or blue-green deployments to limit blast radius
• Add pre-production staging environment that mirrors production traffic patterns
• Run blameless postmortems on every failure to identify systemic causes

Key vocabulary:
• Change failure rate — % of deployments causing a degraded service requiring remediation
• Canary deployment — incremental rollout to a small percentage of traffic before full deployment
• Blameless postmortem — incident review focused on systemic causes, not individual fault

5 / 5

During a team health review, an engineer says: "We improved our deployment frequency from weekly to daily without any increase in our change failure rate." What is the DORA term for this pattern, and why is it significant?

This scenario illustrates the central finding of DORA research: high-performing engineering teams achieve BOTH higher velocity AND higher stability simultaneously — they are not in tension.

The "deployment frequency vs stability" paradox:
Engineering intuition often suggests: deploy more often → more risk → more failures. DORA research across 30,000+ professionals consistently disproves this:
• Elite performers deploy more frequently AND have lower change failure rates than low performers
• The key enabler is automated quality — not slower deployment cadences

What enables high frequency + high stability:

Practice	Effect on CFR
Trunk-based development	Smaller changes = smaller blast radius
Comprehensive automated tests	Catches regressions before production
Canary / progressive delivery	Limits impact of bad deployments
Shift-left security	Security issues caught before merge

The vocabulary to describe this achievement:
• "High deployment frequency with low change failure rate" — the hallmark of elite engineering performance
• "Deployment decoupled from release" — combining frequent deployments with feature flags so production code changes and user-visible features change independently
• "Psychological safety and blameless culture" — DORA research identifies culture as a predictor of technical performance

Key vocabulary:
• DORA elite performer — team achieving high scores on all four DORA metrics simultaneously
• Deployment vs release — deploying code to production (technical) vs making a feature visible to users (business decision)
• Continuous delivery maturity — the organisational capability level enabling elite DORA performance