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.

Navigating Nuance: Expressing Velocity Concerns in Slack

DORA’s focus on velocity – essentially, how quickly a team can reliably deliver value – is often framed around metrics like deployment frequency, change lead time, and service availability. However, translating that concept into everyday conversations, especially when expressing concerns about potential issues, requires more nuanced phrasing than simply “we need to increase our velocity.” It’s not just about speed; it’s about sustainable speed and demonstrable value delivery.

Consider this scenario: You’ve been reviewing a pull request for a new feature, and you notice several small, un-tested changes interspersed with the core implementation. The PR description is brief – “Fixing some bugs” – and there are no clear indications of testing strategy or risk assessment. A simple “We need to speed this up” wouldn’t be helpful. Instead, a more effective approach might be: “I’m seeing a lot of small changes here without explicit test coverage. While I appreciate the quick turnaround, it raises concerns about potential regressions and overall stability. Perhaps we could discuss breaking down the task into smaller, individually tested components? Improving our delivery cadence here would allow us to maintain higher quality and reduce the risk of introducing bugs.” This phrasing uses key DORA-related vocabulary – “regression,” “stability,” “delivery cadence” – demonstrating an understanding of the underlying principles.

Another example: During a sprint planning meeting, a developer is pushing out features with minimal documentation or acceptance criteria. A direct request to “get faster” won’t cut it. A more constructive approach might be: “Let’s focus on ensuring each feature has clear acceptance criteria before we start development. Establishing those upfront will help us track our progress against the sprint goal and measure how effectively we’re delivering value. We can then use metrics like cycle time to understand if we’re truly optimizing our workflow – are we spending too much time re-working features because of unclear requirements?” This highlights the link between clear goals, measurable outcomes (cycle time), and ultimately, velocity.

It’s also vital to acknowledge that simply asking for more velocity can be perceived as demanding or even critical. Framing your requests with empathy and a focus on shared improvement is key. Remember, the goal isn’t to blame anyone; it’s about collaboratively optimizing the process and delivering value consistently.

# Example: Using `git log` to analyze commit frequency (illustrative)
git log --author="John Doe" --since="2 weeks" --graph | head -20

This simple command shows how tracking commit frequency – a key component of DORA’s metrics – can be used as a starting point for discussion, not as a directive. It’s about understanding patterns and identifying areas where the team can improve its flow without sacrificing quality or stability.