DORA Metrics English: How to Discuss Engineering Velocity

Introduction

In modern software engineering, the conversation about team performance has shifted from subjective impressions to measurable outcomes. DORA metrics — developed by the DevOps Research and Assessment team — give engineering leaders a data-driven vocabulary for discussing how fast and how reliably software is delivered. Whether you are in a retrospective, a quarterly business review, or a hiring conversation, knowing these terms precisely will help you communicate engineering velocity with authority and clarity.

DORA Metrics Vocabulary

Deployment frequency — How often an organization successfully releases software to production. High-performing teams deploy multiple times per day; low performers deploy monthly or less. It is one of the two primary throughput metrics in the DORA framework.

“Since we moved to trunk-based development, our deployment frequency has increased from twice a week to an average of nine deployments per day across all services.”

Lead time for changes — The time it takes for a code commit to reach production. This metric measures the entire pipeline from code being written to it running in a live environment, and it reflects the efficiency of review, testing, and deployment processes.

“Our lead time for changes dropped from four days to under six hours after we parallelized our test suites and added automated staging promotion.”

Change failure rate — The percentage of deployments that cause a failure in production, requiring a rollback, hotfix, or other remediation. It is the primary stability metric alongside MTTR, and elite teams typically keep this below 15 percent.

“Our change failure rate spiked to 40 percent after we reduced our automated test coverage — that is the data we used to justify re-investing in the QA pipeline.”

MTTR — Mean Time To Restore, the average time it takes to recover a service after a production failure. Lower MTTR indicates that teams can detect, diagnose, and fix incidents quickly. It is often used alongside change failure rate to measure service reliability.

“We track MTTR weekly on the engineering dashboard — our current average is 22 minutes, and our target for next quarter is under 10 minutes through better runbook automation.”

Throughput — A general term for the volume of work a team delivers over a period of time. In engineering contexts it often refers to the number of pull requests merged, features shipped, or story points completed per sprint. It is distinct from velocity in that it focuses on output rather than relative effort.

“The throughput data shows that the platform team is processing roughly 30 percent more pull requests per week since we adopted a code owner model for review routing.”

Cycle time — The time from when work on a task begins to when it is completed and ready for delivery. Cycle time is typically shorter than lead time because it excludes the waiting period before work starts. Reducing cycle time is a key goal of flow-based engineering management.

“When we plotted cycle time on a scatter chart, we found that most tasks completed in under two days, but a long tail of large tickets was inflating our average — so we introduced a story-point cap of five per ticket.”

Work-in-progress — Commonly abbreviated as WIP, this refers to the number of tasks or features that are actively being worked on but not yet completed. High WIP is associated with context switching, long cycle times, and quality degradation.

“We introduced a WIP limit of three active tasks per engineer after observing that higher WIP correlated directly with longer cycle times and more review bottlenecks.”

Bottleneck — A step in the delivery process where work accumulates faster than it can be processed, slowing the entire pipeline. Identifying and resolving bottlenecks is central to flow engineering and to improving DORA metrics across the board.

“Our value stream mapping exercise revealed that code review was our primary bottleneck — pull requests were waiting an average of two days for a first review before any work resumed.”

Reading DORA Metrics in Context

DORA metrics are most useful when read together rather than in isolation. A team might have high deployment frequency but a rising change failure rate, which suggests they are shipping fast but cutting corners on quality. A team with low MTTR but low deployment frequency may have excellent recovery processes but a slow, risk-averse delivery pipeline. The goal is to improve all four metrics simultaneously, which is the hallmark of an elite DevOps team.

When presenting these metrics to leadership, frame them in terms of business impact. High lead time for changes means slower response to market opportunities. High change failure rate means more customer-facing incidents. High MTTR means longer outages. Low deployment frequency means less frequent value delivery. Translating technical metrics into business language is a core skill for engineering managers and DevOps leaders.

Vocabulary in Practice

If you are participating in an engineering health review or a DevOps maturity assessment, be ready to use these terms precisely. Saying “we want to improve velocity” is vague. Saying “we want to reduce cycle time from 3.5 days to under 2 days and bring our change failure rate below 10 percent” is a measurable, actionable goal. The DORA framework gives you the vocabulary to have that second kind of conversation.