5 exercises — how to explain, present, and discuss the four DORA metrics in engineering reviews and executive meetings.
The 4 DORA metrics
Deployment frequency — how often you ship to production
Lead time for changes — commit to production time
Change failure rate — % of deployments causing incidents
MTTR — Mean Time To Restore after an incident
0 / 5 completed
1 / 5
An engineering director presents to the board: "We've moved from the Low performer tier to the Elite performer tier over the past year — our deployment frequency is now multiple times per day." What does deployment frequency measure, and what is the Elite tier threshold according to DORA research?
Deployment frequency measures how often an organisation successfully releases to production. The four DORA tiers: Elite — on-demand, multiple times per day; High — between once per day and once per week; Medium — between once per week and once per month; Low — fewer than once per month. High deployment frequency correlates with faster feedback loops, lower risk per deployment, and higher team morale. When presenting: "We ship multiple times per day, which puts us in the Elite tier and means each release is small and low-risk." Source: the Accelerate book (Forsgren, Humble, Kim, 2018) and the annual DORA State of DevOps Report.
2 / 5
A CTO reports in a quarterly update: "Our lead time for changes has dropped from two weeks to under four hours — developers are no longer waiting in a queue for manual approval gates." What does lead time for changes measure in the DORA framework?
Lead time for changes measures the time from a code commit being merged to that change running in production — sometimes called "commit-to-deploy time." DORA tiers: Elite — less than one hour; High — one day to one week; Medium — one week to one month; Low — one to six months. Long lead times indicate manual gates, approval bottlenecks, or slow CI pipelines. Key phrase: "Our lead time for changes is currently 45 minutes, which is Elite tier — our CI pipeline and automated approvals are working." From the Accelerate book: lead time is one of the primary levers for organisational agility.
3 / 5
After an incident review, an SRE says: "Our change failure rate spiked to 18% this month — nearly one in five deployments caused a rollback or hotfix." What is the change failure rate, and what does an 18% rate indicate?
Change failure rate (CFR) = the percentage of deployments that cause a failure in production, requiring a hotfix, rollback, or patch. DORA tiers: Elite — 0–5%; High — 5–10%; Medium — 10–15%; Low — 46–60% (counterintuitively, the DORA 2023 report shows Low performers cluster at extremes). At 18%, the team is performing below High tier. Key phrases: "Our CFR is above the High performer threshold — we need to invest in better pre-production testing." and "Every percentage point of change failure rate represents real incident cost." CFR and MTTR are the stability metrics; deployment frequency and lead time are the throughput metrics.
4 / 5
During an incident postmortem, a team lead says: "Our MTTR is currently 45 minutes — that's within the Elite tier and we recovered before most users noticed the outage." What does MTTR stand for in this context, and why does a 45-minute MTTR qualify as Elite?
MTTR = Mean Time To Restore (or Recovery) — the average time from when an incident begins to when service is fully restored. DORA tiers: Elite — less than one hour; High — less than one day; Medium — less than one week; Low — more than one week. At 45 minutes, the team is in the Elite tier. MTTR is improved by: runbooks, automated rollback, observability tooling, and on-call response processes. Key executive presentation phrase: "Our MTTR is 45 minutes on average — for a service with this traffic level, that translates to roughly $12k of recovered revenue per incident compared to our previous 4-hour MTTR." Note: MTTR is also used in hardware contexts (Mean Time To Repair); in software/SRE it always means Mean Time To Restore.
5 / 5
A VP of Engineering reads from the Accelerate book in a team meeting: "The research shows that software delivery performance predicts organisational performance — high-performing teams have better profitability, market share, and productivity." Which statement best describes the core argument of the Accelerate book by Forsgren, Humble, and Kim?
Accelerate: The Science of Lean Software and DevOps (Forsgren, Humble, Kim, 2018) presents four years of research showing that the four DORA metrics — deployment frequency, lead time for changes, change failure rate, and MTTR — form two clusters: throughput (speed of delivery) and stability (quality of delivery). Crucially, the research proves that high throughput and high stability are not in tension — Elite teams achieve both simultaneously. This directly contradicts the idea that you must sacrifice quality for speed. Executive-friendly framing: "The Accelerate research demonstrates that investing in engineering effectiveness is not a cost — it's a predictor of revenue growth and market share." Key vocabulary from the book: value stream mapping, deployment pipeline, trunk-based development, loosely coupled architecture, westrum organisational culture.