DORA Metrics in Plain English: Deployment Frequency, Lead Time, and More

DORA metrics are the four engineering performance indicators developed by the DevOps Research and Assessment team at Google. They are now the standard language for discussing software delivery performance in English-speaking engineering organisations. This guide explains each metric clearly and shows you how to use them in team meetings and written reports.

The Four DORA Metrics

1. Deployment Frequency

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

Categories:

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

In plain English: Deployment frequency tells you how quickly value reaches users. High-frequency deployment is associated with lower risk per deployment (smaller changes) and faster feedback loops.

Team meeting phrases:

• “We’re currently deploying twice a week — our target is to reach daily deployments by Q3.”
• “Deployment frequency dropped last quarter because we were mid-migration — it should recover once the new pipeline is stable.”

2. Lead Time for Changes

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

Also expressed as: commit-to-deploy time, cycle time

In plain English: Lead time reflects how fast your engineering process is. Long lead times usually indicate bottlenecks in testing, review, or deployment pipelines.

Team meeting phrases:

• “Our median lead time is currently four days — the main bottleneck is the integration test suite, which takes three hours to run.”
• “Reducing lead time is a priority this half because it directly affects how quickly we can respond to production issues.”

3. Change Failure Rate

What it measures: The percentage of deployments that cause a production incident and require a hotfix, rollback, or patch.

Formula: (Number of failed deployments ÷ Total deployments) × 100

In plain English: This metric tells you how often your deployments go wrong. Elite teams have a change failure rate of 0–15%. A high change failure rate usually signals insufficient testing, review, or staging environments.

Team meeting phrases:

• “Our change failure rate last month was 22%, which is above our target. We’re reviewing the pre-deployment checklist to identify the gaps.”
• “The spike in change failure rate coincided with the removal of integration tests — restoring them is a priority.”

4. Mean Time to Recovery (MTTR)

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

Also expressed as: mean time to restore, recovery time

In plain English: MTTR measures your team’s ability to respond and recover when things go wrong. Elite teams recover in under one hour. High MTTR often indicates poor observability, complex rollback procedures, or unclear on-call processes.

Team meeting phrases:

• “Our MTTR for P1 incidents is currently 45 minutes — we want to bring that below 30 minutes by improving our runbooks.”
• “We need to invest in better observability before MTTR becomes a problem at our current growth rate.”

Discussing DORA Metrics in Reports

When writing about DORA metrics in engineering reports or strategy documents, use precise language:

Instead of	Use
“We deploy a lot”	“Our deployment frequency is 8.3 deployments per week on average”
“We’re getting faster”	“Lead time for changes improved from 6 days to 2.5 days over the last quarter”
“We had some failures”	“Change failure rate was 18% in March, compared to our target of below 10%”
“We recovered quickly”	“Median MTTR for P1 incidents was 28 minutes in Q1”

Example Sentences

1. “Our deployment frequency increased from weekly to daily after we moved to trunk-based development and implemented automated smoke tests.”
2. “Lead time for changes is currently three days — the longest stage is the code review queue, which averages 36 hours.”
3. “Following three consecutive high-severity incidents, the change failure rate reached 30% in February, prompting a temporary deployment freeze.”
4. “MTTR improved significantly after we centralised our runbooks and added automated alerting for the most common failure modes.”
5. “In our DORA assessment, we classified as a ‘high performer’ on deployment frequency and MTTR, but ‘medium’ on lead time — that’s our focus area for this half.”

Understanding Nuance: Common Phrases & Context

Let’s be honest – talking about “lead time” or “deployment frequency” can feel a little… sterile. It’s easy to get bogged down in the numbers without truly understanding why these metrics matter and how they translate into real improvements for your team. For non-native English speakers, this is especially important. The precise phrasing used when discussing software development performance can vary significantly across cultures, and misunderstandings can easily arise if you’re not familiar with common idioms and accepted communication styles. A simple statement like “we need to reduce our lead time” might be interpreted literally – as a command to shrink the process! – rather than as an invitation to explore bottlenecks and optimize workflow.

It’s also crucial to recognize that technical discussions are rarely conducted in perfectly formal language. While clarity is paramount, you’ll often hear phrases like “let’s iterate on this” or “we need to get to production faster” used casually. These aren’t just buzzwords; they represent a commitment to continuous improvement and responsiveness to user needs. Similarly, understanding the difference between ‘throughput’ (the rate at which work is completed) and ‘velocity’ (the speed at which a team delivers value) can be tricky – velocity often includes factors beyond simply coding time, such as testing and documentation. Being able to articulate why one metric is higher than another requires more than just knowing the definition; it demands an understanding of the underlying processes. Don’t hesitate to ask for clarification if you’re unsure about a phrase or term – asking “Could you explain what you mean by ‘reducing cycle time’ in this context?” is perfectly acceptable and demonstrates a willingness to learn.

Consider a situation where a senior engineer, Sarah, is reviewing a pull request. She might leave a comment on the PR description saying: “This looks good overall, but let’s focus on increasing deployment frequency. We could explore automating some of these steps to reduce the manual effort involved.” This isn’t just about speed; it’s about efficiency and reducing the risk associated with infrequent deployments. It’s a subtle way of suggesting that more frequent releases – even small ones – can lead to faster feedback loops and quicker value delivery.

Finally, let’s look at how you might describe your team’s performance in a Slack channel after a successful sprint: “Great work everyone! We hit our deployment frequency target this week and the lead time on feature X was significantly reduced thanks to the automation improvements we implemented.” This demonstrates not just achievement but also the proactive steps taken to achieve that outcome.

# Example using `git` for analyzing commit history (illustrative)
git log --author="John Doe" --since="1 week" --pretty=format:"%h - %an, %s" | head -n 5

This command would show the last five commits made by John Doe in the past week, providing a quick visual of recent activity and potentially highlighting areas for improvement – perhaps a long lead time between commits.