Why DORA Metrics Matter More Than Velocity
Every sprint planning I've attended has the same ritual. Someone pulls up the velocity chart, the team debates whether last sprint's 42 points was "good," and everyone commits to 45 this time. Two weeks later, the cycle repeats. Nobody asks the question that matters: are we getting better at delivering software?
Velocity measures activity. It says nothing about whether those points translated into value, whether the code was stable, or whether the team is improving. I've seen teams with skyrocketing velocity that couldn't ship a reliable feature to save their lives. And small teams with modest throughput that deployed confidently multiple times a day with near-zero incidents.
The difference? The second group was tracking DORA metrics.
What Are DORA Metrics?
In 2018, Nicole Forsgren, Jez Humble, and Gene Kim published Accelerate: The Science of Lean Software and DevOps. The book distilled years of research into four metrics that predict software delivery performance. Not opinions -- data-backed indicators validated across thousands of organizations.
Deployment Frequency -- how often your team deploys to production. Elite teams deploy on demand, multiple times per day. Low performers deploy monthly or less. This captures your ability to ship small, incremental changes rather than giant, risky releases.
Lead Time for Changes -- the time from code committed to code running in production. Elite teams: under one hour. Low performers: one to six months. Every bottleneck in your pipeline -- code review, CI/CD, testing, approvals -- shows up here.
Mean Time to Restore (MTTR) -- when production breaks, how long to fix it? Elite teams restore in under one hour. Low performers take a week or more. This directly reflects your monitoring, alerting, and incident response.
Change Failure Rate -- what percentage of deployments cause a production failure. Elite teams stay between 0-15%. Low performers exceed 46%. This captures code quality, testing coverage, and pipeline reliability.
The counterintuitive finding: speed and stability are not tradeoffs. The highest-performing teams are both the fastest and the most stable. They deploy more frequently, recover faster, and break less.
Why Velocity Fails You
It's a relative, internal number. Story points mean different things to different teams. A velocity of 60 tells you nothing without deep context about what those points represent. There's no external benchmark.
It incentivizes the wrong behavior. When leadership watches velocity, teams optimize for it. They pad estimates, break stories to inflate counts, and avoid refactoring because it doesn't produce "visible" points. The metric becomes a target, and once a metric becomes a target, it ceases to be a good metric -- Goodhart's Law.
It measures output, not outcomes. A sprint where the team burns 50 points but breaks production for two days? Velocity says great sprint. DORA says disaster.
How to Start Tracking
You don't need a platform. Start simple.
Deployment Frequency. Count production deployments per week from your CI/CD logs. If you're deploying less than once a week, your releases are too big, your branches live too long, or your deployment process is too painful.
Lead Time for Changes. Timestamp of the merge commit minus the first commit on the branch. If it's over a week, find the constraint: code review delays? Slow CI? Manual QA bottleneck?
MTTR. Track production incidents: when detected, when resolved. Even a spreadsheet works. Target under 24 hours initially; under one hour is elite.
Change Failure Rate. Deployments that caused incidents divided by total deployments. Under 15% is elite. Over 30% means your testing pipeline has holes.
The Conversation Changes
When teams switch to DORA metrics, the conversations shift. Instead of "did we hit our sprint commitment?" they ask "why did our lead time spike last week?" Instead of arguing 3 points versus 5, engineers investigate why Thursday's deployment failed.
DORA metrics are leading indicators. A rising change failure rate warns you before the next outage. Increasing lead time signals a bottleneck before it becomes a crisis. Velocity is a lagging indicator of effort at best -- a vanity metric at worst.
Story points can still be useful for sprint planning within a team. But they should never be the metric you report to leadership, use to compare teams, or treat as engineering health. That's what DORA is for.
Making It Stick
Track the four metrics weekly. Put them on a visible dashboard. Discuss trends in retros. Set directional goals: "lead time under 3 days this quarter" is useful. "Increase velocity by 20%" is not.
For the deeper research, read Accelerate by Forsgren, Humble, and Kim. It's the most data-driven book on software delivery I've come across, and short enough for a weekend.
At Conectia, when we integrate senior engineers into a client's team, one of the first things we look at together is how the team measures its own performance. Engineers who understand DORA metrics don't just write code -- they improve the system that delivers the code. That mindset is what separates a developer who fills a seat from one who raises the team's capability.
Looking for engineers who care about delivery performance, not just lines of code? Talk to a CTO -- our senior LATAM engineers bring the practices and mindset that move your DORA metrics in the right direction.
