DORA Metrics in Plain English: How to Discuss Deployment Frequency and MTTR

DORA metrics — developed by the DevOps Research and Assessment team — are the most widely used framework for measuring software delivery performance. If you work in a modern engineering team, you will encounter these metrics in team meetings, leadership reviews, and hiring interviews. This guide explains each metric in plain English and gives you the vocabulary to discuss them confidently.

The Four DORA Metrics Explained

Deployment Frequency

What it measures: How often your team deploys code to production.

Plain English explanation: “Deployment frequency tells us how often we are actually releasing software to real users. A team that deploys multiple times a day can experiment quickly and fix problems fast. A team that deploys once a month carries much more risk in each release and learns much more slowly.”

DORA performance levels:

• Elite: Multiple deploys per day
• High: Once per day to once per week
• Medium: Once per week to once per month
• Low: Less than once per month

Phrases for discussing it:

• “Our deployment frequency has improved from weekly to daily since we introduced continuous deployment.”
• “We are currently in the ‘medium’ DORA band for deployment frequency; our goal for Q3 is to reach ‘high’.”

Lead Time for Changes

What it measures: The time from a code commit being made to that code running in production.

Plain English explanation: “Lead time tells us how quickly an idea can become a live feature. A short lead time means the team can respond rapidly to customer feedback and business needs. A long lead time means changes sit waiting in queues — in review, in testing, or waiting for a deployment window.”

Common vocabulary:

• Cycle time — the time from starting work to completing it (overlaps with, but is not identical to, lead time).
• Deployment window — a scheduled period during which deployments are permitted; a cause of long lead times in less mature teams.

Phrases for discussing it:

• “Our lead time for changes has come down from two weeks to three days since we automated the integration test suite.”
• “The main contributor to our long lead time is the manual security review step — we are exploring ways to shift that left.”

Change Failure Rate

What it measures: The percentage of deployments that cause a production failure requiring a rollback, fix-forward, or hotfix.

Plain English explanation: “Change failure rate tells us how often our deployments go wrong. A high rate means our releases are risky and our testing is not catching issues before they reach users. Elite teams have a change failure rate of 0–5%; many teams hover around 10–15%.”

Phrases for discussing it:

• “Our change failure rate was 18% last quarter — significantly above the DORA high-performer benchmark of 5–10%. We are prioritising test coverage in our core checkout flow to bring it down.”
• “The spike in change failure rate in March correlates directly with the two large releases we pushed without adequate staging testing.”

Mean Time to Recover (MTTR)

What it measures: The average time to restore service after a production incident.

Plain English explanation: “MTTR tells us how quickly we can fix things when they go wrong. No system is perfectly reliable, so MTTR is as important as trying to prevent failures. An elite team recovers in under an hour. A struggling team might take days.”

Key distinction: MTTR is not the same as Mean Time Between Failures (MTBF), which measures reliability. MTTR measures recovery speed.

Phrases for discussing it:

• “Our MTTR improved from 4 hours to 45 minutes after we invested in observability tooling and runbook automation.”
• “The incident last week had an MTTR of 6 hours — well above our target. The post-mortem identified that the detection lag was 90 minutes; we had no alerting on the specific database metric that was the root cause.”

How to Present Metric Trends

When presenting DORA metrics to a team or to leadership, use trend language rather than point-in-time values. Trends tell a story; single values do not.

Positive trend language:

• “Deployment frequency has improved steadily over the past quarter, from once per week to three times per week.”
• “MTTR has trended downward since we introduced the new runbook library — we are seeing consistent improvement month-on-month.”
• “Our change failure rate dropped from 15% in Q1 to 8% in Q2, which we attribute to the introduction of feature flags.”

Negative trend or concern language:

• “We are seeing a worrying uptick in change failure rate over the past six weeks, which warrants investigation.”
• “Lead time has plateaued — it stopped improving in April, and we believe the bottleneck is now in the code review stage rather than the deployment pipeline.”

What to Say When Metrics Are Poor

Being honest about poor metrics while presenting a credible improvement plan builds more trust than minimising the problem.

Framing poor results constructively:

• “Our MTTR of 4.5 hours is not where it needs to be. The root cause is our lack of observability in the payments service; we have a concrete plan to address this in the next sprint.”
• “I want to be transparent: our deployment frequency is in the ‘low’ DORA band. This is a structural issue — we have long-running feature branches and a slow test suite. Here is our plan to address both.”
• “The change failure rate data is uncomfortable but valuable — it tells us exactly where our quality process is breaking down.”

Example Team Meeting Sentences

1. “Looking at last month’s DORA metrics: deployment frequency held steady at daily, lead time improved slightly from 4 days to 3.5 days, but change failure rate crept up to 12% — we need to understand what drove that.”

2. “The 6-hour MTTR on Tuesday’s incident was our worst of the quarter; the post-mortem found two contributing factors: a 2-hour detection lag and a missing runbook for that failure mode. Both are addressable.”

3. “Our goal for Q3 is to move from the DORA ‘medium’ band to ‘high’ on deployment frequency — that means going from weekly to daily deployments, which requires us to break up our current monolithic release process.”

4. “I want to flag that lead time has been flat for eight weeks; we have removed the pipeline bottleneck, which means the constraint is now elsewhere — probably in the code review queue, which averages 2 days per PR.”

5. “The improvement in MTTR from 3 hours to 35 minutes over the quarter is the most encouraging signal in this data — it shows the on-call runbook work from last quarter is paying off.”

Expanding Your Vocabulary: Precision in Technical Discussions

We’ve covered the core concepts of DORA metrics – Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time To Restore (MTTR) – and how to approach discussing them. But a crucial element often overlooked, particularly for developers new to professional English communication, is the precise language needed to articulate these ideas effectively. It’s not just about stating the numbers; it’s about conveying understanding, suggesting improvements, and fostering collaborative problem-solving. Let’s look at some specific phrases and scenarios that will help you build confidence in your technical discussions.

One common challenge is framing feedback during a code review. Instead of simply saying “This takes too long,” which can feel accusatory, consider something like: “I noticed the lead time for this change is longer than our target. Could we explore ways to streamline the testing process? Perhaps adding a unit test here would reduce the overall time?” Similarly, when discussing MTTR with a teammate after an outage, avoid vague statements. Instead, you could say, “The MTTR was significantly higher than expected during that incident. Let’s analyze the root cause and identify steps we can take to improve our response times – perhaps documenting clearer escalation paths or automating some of the initial troubleshooting.” Using terms like “streamline,” “root cause analysis,” and “escalation paths” demonstrates a deeper understanding of operational processes.

Another key area is describing trends in your PR descriptions. Rather than simply stating “Increased deployment frequency,” try something more specific: “Deployment frequency has increased by 15% over the last quarter, largely due to the adoption of our new CI/CD pipeline. This presents an opportunity to further optimize our release process and potentially reduce lead time.” Phrases like ‘adoption,’ ‘optimize,’ and ‘potential’ add a layer of sophistication that demonstrates you’re not just reporting data but thinking critically about its implications. Remember, clear communication is about more than just conveying information; it’s about building trust and shared understanding within your team.

Finally, when presenting DORA metrics to stakeholders – perhaps during a sprint retrospective – avoid jargon. Instead of “The change failure rate is elevated,” you might say: “We’ve observed an increase in the number of deployments that require rework. This suggests we need to focus on improving our testing and validation processes.” Using simpler language, combined with visual aids like charts showing trends, will ensure everyone understands the situation and can contribute meaningfully to finding solutions. Focusing on impact – “reducing rework” – is often more persuasive than simply stating a technical metric.