DORA Metrics Communication Language — Code Quality Exercises

1 / 5

An engineering director opens the quarterly review meeting with: "Our deployment frequency is currently weekly. The goal for next quarter is to reach on-demand deployment — multiple times per day. What changes do we need to enable that?" What is deployment frequency and why does the director frame it as a capability goal?

Deployment frequency is one of the four DORA (DevOps Research and Assessment) metrics established by Google DORA research as the strongest predictors of software delivery performance and organisational outcomes.

The four DORA metrics:

Metric	What it measures	Elite benchmark
Deployment frequency	How often code is deployed to production	Multiple times per day (on-demand)
Lead time for changes	Time from commit to production	Less than one hour
Change failure rate	% of deployments causing incidents	0–15%
MTTR (time to restore)	Time to recover from a failure	Less than one hour

Why "on-demand" requires capability building:
• Automated test suite with high coverage (fast safety net for each deployment)
• CI/CD pipeline that deploys automatically on every merge to main
• Feature flags to separate deployment from release
• Trunk-based development (short-lived branches, frequent integration)
• Observability to detect and recover quickly from failures

Language for DORA discussions:
• "We're currently in the 'high' performer band for deployment frequency; elite is on-demand."
• "To increase deployment frequency, we need to invest in test automation first."

Key vocabulary:
• Deployment frequency — how often an organisation successfully deploys to production
• On-demand deployment — the elite DORA benchmark: deploying whenever ready, multiple times per day
• DORA metrics — the four key engineering performance indicators from Google's DevOps research
• Capability goal — a target that requires building new engineering practices, not just more effort

2 / 5

In a sprint review, the team lead presents: "Our lead time for changes is currently averaging 12 days. That means a feature a developer commits today won't reach production for nearly two weeks. We need to understand what's blocking the pipeline." What does lead time for changes measure, and how would you discuss this with management?

Lead time for changes is arguably the DORA metric that best exposes pipeline bottlenecks because it measures the total elapsed time across all delivery stages from commit to production.

DORA performance bands for lead time:

Band	Lead time
Elite	Less than one hour
High	Between one day and one week
Medium	Between one week and one month
Low	More than one month

Common sources of lead time delay (value stream mapping):
① Code review queue — PRs waiting hours or days for reviewers
② Long-running CI — test suites taking 45–90 minutes discourages frequent integration
③ Manual approval gates — human sign-off required before staging/production promotion
④ Release windows — deployments only allowed on specific days/times
⑤ Staging environment contention — shared environments with booking queues

Reporting to management:
• "Our lead time of 12 days places us in the medium performer band; elite performers average under an hour."
• "We've mapped the value stream and found that 8 of the 12 days are spent waiting in the code review queue and staging environment."
• "Investing in parallel test environments and a review SLA policy would cut lead time by an estimated 60%."

Key vocabulary:
• Lead time for changes — elapsed time from code commit to code running in production
• Blocking the pipeline — a stage in the delivery process that causes code to wait, increasing lead time
• Value stream mapping — a technique to visualise all stages of the delivery process and identify waste
• Performance band — the DORA classification of teams into elite, high, medium, or low performers

3 / 5

After a major production incident, the CTO asks in the post-mortem: "What was our MTTR on this one?" The on-call engineer replies: "Four hours from first alert to full service restoration." The CTO says: "That's in the medium performer band. We need to drive MTTR down systematically." What does MTTR mean in this context, and what does "drive MTTR down systematically" imply?

MTTR (Mean Time to Restore) is one of the most operationally important DORA metrics because it measures an organisation's resilience and recovery capability when things inevitably go wrong.

MTTR performance bands (DORA):

Band	MTTR
Elite	Less than one hour
High	Less than one day
Medium	Less than one week
Low	More than one week

"Drive MTTR down systematically" — key capabilities:
• Observability: structured logging, distributed tracing, dashboards — detect failures in seconds, not minutes
• Alert quality: actionable alerts with runbook links; eliminate alert fatigue from noise
• Runbook automation: scripted recovery steps that on-call engineers execute (or that run automatically)
• Feature flags / kill switches: disable a broken feature in seconds without a deployment
• Rollback automation: one-command rollback to previous known-good deployment
• Game days / chaos engineering: practice incident recovery before real incidents happen

Post-mortem and management language:
• "MTTR was four hours — above our target. The delay was primarily in diagnosis, not recovery."
• "We're investing in structured logging to reduce time-to-diagnosis from hours to minutes."
• "Our MTTR improvement plan: feature flags deployed by Q2, automated rollback by Q3."

Key vocabulary:
• MTTR — Mean Time to Restore; average time from incident detection to full service recovery
• Drive MTTR down — systematically reduce average incident recovery time through engineering investments
• Observability — the ability to understand system internal state from external outputs (logs, metrics, traces)
• Kill switch — a feature flag that immediately disables a problematic feature without deployment

4 / 5

A VP of Engineering presents to the board: "Our change failure rate has dropped from 23% to 8% over six months. This reflects our investment in automated testing and deployment practices, and it puts us firmly in the high performer band." What does change failure rate measure, and why is a reduction from 23% to 8% strategically significant?

Change failure rate directly measures the quality and stability of the deployment process — a high rate signals inadequate testing, poor release practices, or insufficient observability.

DORA performance bands for change failure rate:

Band	Change failure rate
Elite	0–15%
High	0–15% (same range as elite; distinction is in other metrics)
Medium	0–30%
Low	16–30% or more

Why 23% → 8% is strategically significant:
• At 23%: every 4th deployment requires emergency attention — on-call engineers are regularly pulled into unplanned incidents
• At 8%: roughly 1 in 12 deployments fails — on-call load significantly reduced; team can focus on features
• Each prevented failure avoids: incident response time, customer impact, post-mortem overhead, and reputational cost

What investments drive change failure rate down:
• Comprehensive automated test suites (unit, integration, end-to-end)
• Progressive delivery (canary deployments, feature flags) to limit blast radius
• Pre-production environments that accurately mirror production
• Static analysis and security scanning in the CI pipeline

Reporting language for management:
• "Our change failure rate improvement from 23% to 8% means our on-call engineers are responding to 3× fewer incidents."
• "We're now in the high performer band; our next focus is reducing MTTR to reach elite."

Key vocabulary:
• Change failure rate — the percentage of deployments that cause a production failure requiring remediation
• High performer band — a DORA classification for teams with strong but not yet elite delivery performance
• Blast radius — the scope of user and system impact when a deployment fails
• Progressive delivery — deploying changes gradually to a subset of users to limit failure blast radius

5 / 5

During a quarterly business review, the engineering manager presents: "We're tracking all four DORA metrics. We're elite on deployment frequency and lead time, but medium on MTTR and change failure rate. This tells us our delivery speed is outpacing our stability practices." What insight is the manager communicating, and what should the team prioritise?

"Delivery speed outpacing stability practices" is a common and important DORA insight — elite performers excel across all four metrics simultaneously, not just the throughput metrics.

DORA metrics as two paired dimensions:

Dimension	Metrics	This team's position
Throughput (speed)	Deployment frequency + Lead time	Elite — strong
Stability (reliability)	MTTR + Change failure rate	Medium — needs work

The key DORA research finding:
Elite performers are high on both dimensions simultaneously — speed and stability are not a trade-off. Teams that sacrifice stability to gain speed end up spending more time on incidents, and net throughput decreases over time.

Priority investments to improve stability metrics:
• For change failure rate: increase test coverage, add canary deployments, run pre-production smoke tests
• For MTTR: implement structured observability (metrics, logs, traces), write and test runbooks, add automated rollback

Language for this strategic conversation:
• "We've built elite delivery speed — now we need to match it with elite stability."
• "The instability is actually limiting our speed advantage: each incident pulls engineers off features."
• "Our Q3 OKR is to reach the high performer band on both MTTR and change failure rate."

Key vocabulary:
• Delivery speed — how fast the team moves code from development to production (throughput metrics)
• Stability practices — engineering disciplines that ensure deployments are reliable and recoverable
• Outpacing — moving faster in one area than a related area can support or sustain
• Elite performer — the top DORA band; teams that excel on all four metrics simultaneously