Stop Blaming Agile: Measure Decision Latency Instead

Here's a number that should stop you cold: 75% of projects with good decision latency succeed, versus only 21% with bad latency (Standish Group CHAOS Report). That's from the CHAOS 2020 research, and it's the most important stat in project management right now. We've spent two decades arguing over Scrum vs. Kanban vs. Waterfall, but the data says the methodology barely matters. What matters is how fast and how well your team makes decisions. As an editor who's watched teams drown in process, I'm done pretending otherwise.

This article is for anyone who's tired of the methodology wars—team leads, product managers, and coaches who want a practical way to improve delivery without another framework overhaul. I'm going to walk you through how to measure decision latency and turn it into a tool for improvement. No theory. Just steps.

1. Stop Measuring the Wrong Things

First, admit that your current metrics are probably lying to you. Velocity, story points, cycle time—these are all useful, but they're outputs, not causes (Atlassian Agile metrics). A team can have great velocity and still deliver the wrong thing because a product owner waited three weeks to make a call. The CHAOS data suggests that decision latency—the time it takes to make and communicate a decision—is the real bottleneck. So stop obsessing over burndown charts and start tracking how long it takes to move a decision from 'we need to decide' to 'we have decided.'

2. Define What a Decision Is

Before you can measure latency, you have to know what counts. In my experience, a decision is any choice that affects the product direction, scope, or implementation—like 'should we build X or Y?' or 'is this bug a blocker?' Write down a list of typical decisions your team faces. Keep it simple. If you can't name three decisions you made last week, that's a red flag. The Scrum Guide says the Product Owner is one person, not a committee (Scrum Guide 2020). That's a good start: if your decisions are made by committee, you're already in trouble.

3. Track the Latency for a Week

For one week, every time a decision gets made, note the date it was first raised and the date it was finally settled. That's your raw latency. Also record who made the decision and how it was communicated. Don't over-engineer this—a simple spreadsheet works. You're looking for patterns. Are most decisions made in the daily standup? Do they wait for a weekly meeting? Is the product owner the bottleneck? You'll see it quickly. In the 17th State of Agile Report, organizational resistance to change and insufficient leadership understanding were the top reasons Agile wasn't scaling (Digital.ai). That's code for 'decisions aren't getting made.'

4. Calculate Your Decision Velocity

Now, turn that data into a number. I like to use a simple metric: decision throughput, which is the number of decisions made per week, and decision lead time, which is the average time from request to decision. If your lead time is more than a few days, you're in the bad-latency zone. For example, if your team averages 10 decisions a week and each takes 5 days, you're losing a week of progress on every significant choice. That's worse than any sprint planning mistake. The Agile Manifesto says 'individuals and interactions over processes and tools' (Agile Manifesto). Decision latency is the ultimate measure of whether you're actually doing that.

5. Fix the Bottlenecks

Once you see the data, you can act. The most common bottleneck is that the Product Owner is trying to decide everything alone. The Scrum Guide says the Product Owner remains accountable, but they can delegate work (Scrum Guide 2020). Use that. Empower the team to make decisions within clear boundaries. For instance, the team can decide on technical implementation details without asking, as long as they meet the Definition of Done. Another fix is to set a decision deadline: if a decision isn't made by Friday, it defaults to the team's recommendation. That forces action. Kanban's principle of limiting work in progress applies here, too—limit the number of open decisions (Atlassian Kanban).

6. Watch Out for the 'Decision Doom' Loop

Here's what can go wrong: you'll measure latency, find a bottleneck, and then someone will 'solve' it by creating a decision log or a weekly decision meeting. That just adds more process. I've seen it happen. The fix is to keep it lean. Lean thinking starts with the customer and aims for zero waste (Lean Enterprise Institute). If a decision meeting doesn't produce decisions, it's waste. Cut it. Also, beware of the analysis-paralysis trap: the CHAOS report says decision latency is about speed, not deliberation. A good decision made in two days beats a perfect decision made in two weeks.

7. Make It a Habit

After a week of tracking, you'll have a baseline. Now, make decision tracking a regular part of your retrospective. Every sprint, ask: what decisions were slow, and why? The Sprint Retrospective's purpose is 'to plan ways to increase quality and effectiveness' (Scrum Guide 2020). Use that time to improve your decision process, not just your code. You don't need a new framework—you need a new habit. In the 17th State of Agile, 71% of organizations use Agile, but only 11% are very satisfied (Digital.ai). That gap isn't about methodology; it's about how decisions are made. Fix that, and the satisfaction will follow.

What I'd Actually Do

Here's my recommendation: for the next two weeks, track every decision your team makes. Write down the date raised, the date decided, and who decided. At the end of each week, calculate your average decision lead time. If it's more than three days, pick one bottleneck and fix it immediately. Don't wait for a sprint boundary. Make it a rule that the team can proceed with the best available option if no decision arrives within two days, and then review it in the next retrospective. That's it. You don't need a new methodology. You need to start measuring the thing that actually matters. The data is clear: decision latency is the biggest success factor. Start there.

Sources

• Standish Group CHAOS Report - https://www.standishgroup.com/
• Scrum Guide 2020 - https://scrumguides.org/scrum-guide.html
• Atlassian (Agile metrics) - https://www.atlassian.com/agile/project-management/metrics
• Atlassian (Kanban) - https://www.atlassian.com/agile/kanban
• Agile Manifesto - https://agilemanifesto.org/
• 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/
• Lean Enterprise Institute - https://www.lean.org/explore-lean/what-is-lean/