Why Sprint Planning Is Broken (And What to Do Instead)
You know the ritual. It's Monday morning. The team files into a conference room - or a Zoom call that should have been shorter. Someone pulls up the backlog. And then, for the next two hours, smart people with graduate degrees hold up fingers to guess how long things will take.
Sprint planning is broken. Not because the people doing it are bad at their jobs, but because the process itself is built on a faulty assumption: that humans can accurately estimate work they don't fully understand.
Here's what's actually going wrong, and what you can do about it.
The Estimation Theater Problem
Two-thirds of software projects suffer from cost overruns (Standish Group). The average overrun is 1.8x the original estimate. A meta-analysis of software estimation studies found a mean effort overrun of 30%.
These numbers haven't improved meaningfully in twenty years. We've tried planning poker, t-shirt sizing, ideal days, and story points. The estimates keep missing. And yet, every two weeks, teams sit down and do it all over again.
Why?
Because sprint planning is broken at most companies - it is a performance. It has the form of rigor without the substance of rigor. People assign numbers to work they haven't fully scoped, using a measurement system (story points) that explicitly refuses to map to real time, and then everyone acts surprised when the sprint doesn't go according to plan.
"We don't have an estimation problem. We have a visibility problem. Teams estimate badly because they can't see what a feature actually touches until they start building it." - Sahil Singh, Founder & CEO of Glue
This isn't a hot take. It's what the data shows.
The Two-Hour Tax
Consider what sprint planning actually costs. A team of six engineers in a two-hour planning session is twelve person-hours of engineering time. That's a day and a half of development capacity. Every sprint.
If the estimates were accurate, this might be a reasonable investment. But with a 30% mean overrun, teams are spending 10-15% of their capacity on a ceremony that doesn't produce reliable numbers. That's not process. That's theater.
Why Story Points Fail
Story points were supposed to solve the estimation problem by separating effort from time. The idea: estimate relative complexity without committing to hours or days. Compare new work to past work. Use velocity to predict capacity.
In practice, story points fail for three specific reasons - and they help explain why sprint planning is broken at a structural level.
1. They're Subjective by Design
A "5-point story" means something different to every team and every engineer. The same feature estimated by two teams will produce wildly different numbers. This isn't a bug - the story point system was designed this way. But it means the numbers don't carry information outside the team that produced them, and even within that team, calibration drifts constantly.
If you're wrestling with this issue, you're not alone. It's a topic we've explored in depth.
2. They Ignore Hidden Dependencies
The biggest source of estimation error isn't misunderstanding complexity - it's not knowing what a change will touch. A feature that looks like a 3-pointer becomes an 8 when you discover it requires changes to the authentication layer, the billing module, and three shared components nobody remembered existed.
Story points can't account for dependencies the team doesn't know about. And without visibility into the actual codebase, teams don't know about dependencies until they hit them mid-sprint.
3. Velocity Is a Lagging Indicator
Velocity - the number of story points completed per sprint - is supposed to make future planning predictable. In theory, if you completed 40 points last sprint, you can plan for roughly 40 this sprint.
But velocity is backward-looking. It tells you what happened, not what will happen. And because story points are subjective, velocity is subject to well-documented inflation. Teams unconsciously (or consciously) inflate point values to hit targets. Velocity goes up. Actual output doesn't.
Gitnux found that 65% of product managers find roadmapping the hardest part of their job. Productboard reported that 70% of large enterprises take at least 1-2 months to make key product decisions. These aren't symptoms of lazy teams. They're symptoms of a planning system built on sand.
The Root Cause: No Visibility
Strip away the process debates - Scrum vs. Kanban, story points vs. t-shirt sizes, two-week sprints vs. one-week sprints - and the reason sprint planning is broken comes down to the same root cause every time.
Teams estimate badly because they can't see what they're estimating.
When an engineer looks at a ticket that says "add export-to-CSV functionality," they're doing mental archaeology. What module handles exports? Is there an existing pattern? Which API endpoints are involved? What about the database layer? Are there shared utilities or do we need to build from scratch?
Most of that mental archaeology happens during estimation, which means the estimates are based on incomplete discovery. The engineer spends two minutes thinking about a task they'd need two hours to actually scope.
The Information Gap
The information needed for accurate estimation exists. It's in the codebase. The files that would need to change, the dependencies between modules, the patterns the team follows - all of this is knowable. But it's knowable only by people who either wrote the code or spent hours reading it.
This creates a bottleneck: the engineers with the most codebase knowledge become the only people who can estimate accurately. Everyone else is guessing. And when those senior engineers leave, the guesses get worse.
For a deeper look at how sprint estimation works and where it breaks, see our glossary entry on the topic.
Better Approaches to Planning
If sprint planning is broken because of estimation theater, what's the alternative? Here are three approaches that address the root cause instead of applying another layer of process on top of a broken foundation.
1. Scope Before You Estimate
The simplest improvement: don't estimate until you've scoped. Real scoping means identifying the actual files that need to change, the dependencies involved, and the patterns to follow - before anyone assigns a number.
This is harder than it sounds. Traditional scoping requires a senior engineer to read through the relevant code, trace dependencies, and write up findings. That takes hours per feature.
AI-powered codebase analysis tools can compress this significantly. Instead of a senior engineer spending two hours tracing dependencies for a single feature, a tool connected to your codebase can surface the affected files, dependencies, and risks in seconds.
Glue's Dev Plans feature does exactly this: you describe a feature, and it generates an implementation plan with the exact files that need to change, dependencies to watch, and patterns to follow. This turns the two-hour pre-estimation scoping exercise into a two-minute query.
2. Replace Points with File-Level Impact Maps
Instead of asking "how complex is this?" ask "what does this actually touch?"
A file-level impact map for a feature shows:
- Which files need modification
- Which modules are affected
- What shared dependencies are involved
- Where the risk concentrations are
This is concrete, verifiable information. It doesn't depend on individual judgment. Two engineers looking at the same impact map will agree on what it shows, even if they'd disagree on story point values.
When your planning tool can connect to your codebase - the way Glue connects to GitHub repositories - generating these impact maps becomes automatic. The team stops debating abstract complexity and starts discussing concrete scope.
3. Use AI for Technical Discovery, Not Just Writing
Most teams using AI for sprint planning use it to write tickets or refine acceptance criteria. That's useful, but it doesn't solve the visibility problem.
The higher-value use of AI in planning is technical discovery:
- "What files would adding role-based access control touch?"
- "Do we already have a pattern for export functionality?"
- "What are the dependencies between the notification system and the user service?"
These are the questions that, when answered before estimation, make estimates dramatically more accurate. They're also the questions that normally require interrupting your most senior engineers.
Tools that connect AI to your actual codebase - not generic AI that guesses about architecture - can answer these questions instantly, with specific file references your team can verify.
Making the Shift
You don't need to abandon sprint planning entirely. You need to fill the information gap that makes it fail.
Here's a practical starting point:
- Pick your three most mis-estimated features from the last quarter. Examine what the team didn't know at planning time that they discovered during implementation.
- Map those unknowns to information sources. In most cases, the missing information was in the codebase - dependencies, shared modules, or legacy patterns nobody remembered.
- Test a codebase-connected tool on your next sprint. Before your next planning session, run your highest-uncertainty tickets through a tool like Glue and share the file-level impact analysis with the team. Measure whether estimates improve.
The goal isn't perfect estimates. Perfect estimates don't exist in software. The goal is estimates that are wrong by 10-15% instead of 80%. That difference is the difference between a team that ships predictably and a team that's constantly apologizing for missed deadlines.
Sprint planning is broken - not because people are bad at guessing, but because we keep asking people to guess when the answers are sitting in the codebase, waiting to be read.
Frequently Asked Questions
Why does sprint planning fail?
Sprint planning fails primarily because of an information gap, not an estimation methodology gap. Teams estimate work they haven't fully scoped. They can't see the actual files a feature will touch, the hidden dependencies between modules, or the patterns they'll need to follow - until they start building. The Standish Group reports that 66% of software projects experience cost overruns, with the average project costing 1.8x its original estimate. Better visibility into the codebase before estimation is the most effective fix.
Are story points useful?
Story points have limited utility. They were designed to separate effort from time, but in practice they're subjective (a "5" means different things to different engineers), they can't account for hidden dependencies, and the velocity metric they feed is prone to inflation. For teams with strong institutional knowledge and stable codebases, story points can provide rough directional guidance. For teams dealing with complex, interconnected systems - which is most teams - file-level impact analysis provides more actionable planning data.
What's better than story points?
The most effective alternative to story points is scope-first planning: identifying the actual files, dependencies, and risks involved in a feature before assigning any estimate. File-level impact maps - generated by connecting AI to your codebase - give teams concrete, verifiable scope information. This replaces subjective complexity debates with objective technical discovery. Teams can then estimate based on known scope rather than guessed complexity, which research suggests can reduce the typical 30% effort overrun significantly.