Your Agile Is Not the Problem—Your Decision Latency Is

Imagine you're a product owner in a 10-person Scrum team. You've got a refined backlog, your sprints run like clockwork, and you're hitting your velocity targets. Yet your stakeholders keep complaining that features take too long to ship. You dig into the data and find that the average time from a user story being “in progress” to “done” is 18 days, even though the work itself takes only 3 days. The rest? Waiting for decisions—on scope, on design, on approvals. You're not alone.

Here's the blunt truth: most teams obsess over which methodology to adopt and ignore the one metric that actually predicts success. The Standish Group CHAOS 2020 report found that decision latency is the biggest success factor—75% of projects with good decision latency succeed, versus just 21% with bad latency. That's a 54-point gap, larger than the difference between Agile and Waterfall success rates (42% vs. 13%). So if you're still debating Scrum vs. Kanban while your decisions crawl, you're rearranging deck chairs on the Titanic.

Why your data analysis is lying to you

You're probably tracking velocity, story points, and maybe cycle time. Those are useful, but they don't capture the hidden killer. Velocity tells you how much work you complete per sprint, but it says nothing about how long work sits idle waiting for a decision. Cycle time—the total time an issue spends from “in progress” to “done” (Atlassian)—does include wait time, but most teams don't slice it. They look at the average and miss the fat tail. That 18-day cycle time with 3 days of actual work is a red flag: 15 days of waste.

Worse, you might be comparing velocity across teams. Don't. Velocity is measured in story points, which are relative and team-specific. Atlassian explicitly warns against cross-team comparisons. Instead, use cycle time and lead time to spot bottlenecks. If your cycle time is long and inconsistent, your delivery is unpredictable—no matter how many story points you burn.

The counterargument (and why it's wrong)

Some agilists will tell you that decision latency is a leadership problem, not a team problem. They'll say, “We can't control how fast the steering committee meets.” That's a cop-out. You can control what you escalate, how you frame decisions, and whether you empower the team to decide locally. The Scrum Guide 2020 says the Scrum Team is self-managing and cross-functional. If your team can't decide on a user story's acceptance criteria without a three-day email chain, you've defeated the purpose. Yes, some decisions need executive input, but most don't. Your job is to shrink the decision surface area.

A practical playbook for measuring and fixing decision latency

Start by instrumenting your workflow. Don't just track cycle time—track the time an item spends in each state, especially waiting states. Use your Kanban board to visualize flow and limit work in progress. Atlassian notes that Kanban limits WIP to expose bottlenecks. If you see a pile-up in “Ready for Review” or “Awaiting Approval,” that's your decision latency hotspot.

Next, define explicit decision rules. For example, any user story estimated at 5 story points or fewer can be approved by the product owner alone within 4 hours. Anything larger requires a 15-minute huddle with the tech lead. This isn't bureaucracy; it's a service-level agreement for decisions. Measure your compliance and adjust.

Finally, make decision latency a first-class metric in your retrospectives. The Sprint Retrospective is “to plan ways to increase quality and effectiveness” (Scrum Guide 2020). Ask: “What decision slowed us down this sprint? How can we decide faster next time?”

What good looks like

Suppose your team runs two-week sprints. You notice that user stories often wait 5 days for a design decision. You introduce a rule: any design decision that affects only one component is made by the team within 2 hours; cross-component decisions get a 30-minute daily design huddle. Within a month, your average cycle time drops from 18 days to 9 days. Your throughput doubles without adding people. That's the power of attacking decision latency.

• Track decision latency separately from cycle time.
• Empower the team to make local decisions.
• Set explicit decision SLAs and measure compliance.

Don't get me wrong: methodology matters. Agile projects are more successful than Waterfall (42% vs. 13% per CHAOS 2020), and Scrum provides a solid framework. But methodology alone won't save you. The 17th State of Agile Report found that 71% of organizations use Agile, yet only 11% are “very satisfied” (Digital.ai). The gap isn't the framework—it's how you execute, and execution hinges on fast decisions.

So stop tweaking your sprint length and start measuring decision latency. Your data will thank you.

Sources

• Standish Group CHAOS Report - https://www.standishgroup.com/
• 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/
• Atlassian (Agile metrics) - https://www.atlassian.com/agile/project-management/metrics
• Scrum Guide 2020 - https://scrumguides.org/scrum-guide.html