Stop Measuring Velocity; Start Measuring Decision Latency

Imagine you're a product owner. Your team just finished a sprint. You have a new feature ready to ship, but you need one approval from a stakeholder who's out until next week. The sprint was a success by every metric—velocity hit its target, all stories met the definition of done. Yet the feature sits idle. That's the problem with how we analyze methodology performance: we measure the wrong things.

Here's the thesis: most teams obsess over velocity and story points, but the data that actually predicts success is decision latency. If you want to improve delivery, stop tracking how much work you do and start tracking how fast you decide.

Velocity is a comfort metric, not a success metric

Velocity—the average amount of work a team completes per sprint, measured in story points—is useful for forecasting. But Atlassian warns that teams should resist comparing velocity across teams. The moment you use it as a performance target, you've turned a planning tool into a vanity metric. Teams game it. They inflate estimates. They split stories to hit a number. None of that improves outcomes.

The Standish Group's CHAOS 2020 report found that agile projects succeed 42% of the time, versus 13% for waterfall. That's a strong argument for agile. But it doesn't tell you which agile practices matter. The same report identified decision latency as the biggest success factor: 75% of projects with good decision latency succeed, compared to 21% with bad latency. That's a massive gap. And it has nothing to do with how many story points you burn per sprint.

So why do we keep measuring velocity? Because it's easy. It's a number that goes up and to the right. Decision latency is harder to quantify, but it's the lever that actually moves success rates. If your team takes three days to decide on a design change, you're losing time that no amount of story point precision can recover.

What decision latency looks like in practice

Decision latency is the time between when a decision is needed and when it's made. It's not a metric you'll find in most agile dashboards. But you can measure it. Start by logging every decision that blocks progress: architecture choices, priority calls, approval gates. Track how long each one sits unresolved. You'll quickly see patterns.

Consider a typical scenario: a team using Scrum holds a 15-minute daily stand-up. They identify a blocker: the API contract isn't finalized. The product owner says they'll check with the architect. That check takes two days. Meanwhile, developers work on lower-priority items. The sprint goal is at risk. Velocity for that sprint might still look fine because they completed other stories. But the value delivery—the thing that matters—was delayed.

Now contrast that with a team that has a clear decision-making protocol. When a blocker arises, the product owner has authority to make a call within hours, or they escalate immediately. That team's decision latency is low. According to CHAOS 2020, they're three and a half times more likely to succeed.

The strongest counterargument: frameworks don't matter

Some will argue that methodology choice is irrelevant—that good teams succeed regardless. There's truth to that. The 17th State of Agile Report found that 71% of organizations use agile, but only 11% are 'very satisfied' with their practice. And 34% either create their own framework or follow none at the enterprise level. So clearly, the framework itself isn't a magic bullet.

But that doesn't mean methodology doesn't matter. It means the wrong methodology—or the right one applied poorly—doesn't help. Decision latency is a methodology-agnostic metric. You can have low latency in Scrum, Kanban, or even waterfall. The difference is that agile methods, when implemented well, are designed to shorten feedback loops. Scrum's sprint review, for example, is timeboxed to four hours for a one-month sprint and should never be a gate to releasing value. That's a built-in mechanism to reduce decision latency. But if your organization treats it as a status meeting, you lose that benefit.

The counterargument fails because it conflates framework adoption with framework effectiveness. The data says otherwise: decision latency predicts success far better than methodology labels.

How to reduce decision latency

You don't need a new framework. You need to change how decisions get made. Here are three concrete moves:

• Empower the product owner to make scope and priority calls without waiting for a committee. The Scrum Guide says the product owner is one person, not a committee, and remains accountable for backlog management even when delegating.
• Set a decision SLA. For example, any blocker raised in daily stand-up must be resolved or escalated within 24 hours. Track compliance.
• Measure cycle time, not just velocity. Cycle time is the total time an issue spends from 'in progress' to 'done.' Shorter and more consistent cycle times indicate higher throughput and more predictable delivery. If cycle time is creeping up, decision latency is often the culprit.

These are not radical changes. They're operational discipline. And they work across any methodology.

Bottom line

The single best move is to start tracking decision latency alongside your delivery metrics. Stop optimizing velocity in isolation. Use the CHAOS data as your guide: 75% of projects with good decision latency succeed. That's the number that should be on your dashboard.

Sources

• Standish Group CHAOS Report - https://www.standishgroup.com/
• Atlassian (Agile metrics) - https://www.atlassian.com/agile/project-management/metrics
• Scrum Guide 2020 - https://scrumguides.org/scrum-guide.html
• Digital.ai (17th State of Agile) - https://digital.ai/press-releases/17th-state-of-agile-report-71-use-agile-in-their-sdlc-small-organizations-report-strong-business-benefits-medium-and-larger-sized-companies-continue-to-experience-barriers-in-successfully-scaling-a/