Scrum has a problem that its defenders rarely admit: it doesn’t fit most software development, and it doesn’t fit the managers and business owners who have to plan around it. The usual response — “it’s just a lightweight framework, not a complete operating system” — sounds humble but functions as an excuse. It lets the framework off the hook for problems it actively creates.
This post lays out the case. Not as a rant, but as a structural critique: Scrum was built for prototyping, was relabeled for software, and the industry has spent two decades blaming teams for the resulting mismatch.
The core thesis
Scrum is a prototyping methodology mislabeled as a software development framework. Its DNA — time-boxed exploration, resettable iterations, relative sizing of unknown work, inspect-and-adapt cycles — is native to prototyping. None of it is native to the continuous evolution of a living codebase.
When you impose a prototype rhythm on continuous work, you get friction, false closure, and corrupted numbers. And when businesses try to plan on those numbers, they get something worse: decisions made on information that doesn’t mean what it appears to mean.
1. Estimation failures
Estimation is where Scrum starts to go wrong. The framework uses relative sizing — story points — to avoid committing to hours. The intent is to sidestep false precision, but the result is a number that looks rigorous and isn’t.
- Points are vague and unanchored. Relative sizing produces a number that means nothing outside the team’s own scale — and drifts even there over time.
- Points ignore dependencies. A story sized “8” in isolation can sit on a critical path far longer than the number implies. The method has no concept of dependency structure.
- Systematic underestimation. Isolated relative sizing hides integration work, unknowns, and cross-team waits. Large software projects routinely overrun by 100–200%.
- No cost information. Points deliberately abstract away money, so estimation produces no business-relevant input.
- Spikes reveal a points-to-time relationship the framework then forbids you to use — creating a calibration the team must pretend not to have.
2. Forecasting failures
Velocity is the bridge from points to time. It’s the only legitimate points-to-time relationship in Scrum, and it’s also the weakest part of the system. It samples the past, assumes the future looks like it, and offers no way to detect when that assumption breaks.
- Velocity samples the past. It assumes the future distribution matches history — and has no mechanism to detect when it doesn’t (new tech, new team, new domain).
- It’s team-specific and non-comparable. You can’t use it across teams, yet it’s the only number available to plan with.
- It’s easily gamed. The moment velocity becomes a target, teams inflate estimates, split stories, weaken the Definition of Done, or sandbag.
- The points-to-time bridge is statistical, not a real cost rate. Forecasts look rigorous and aren’t.
- Same flaw as Kanban forecasting: historical distributions don’t reflect changed conditions.
3. The structural mismatch with software
This is the heart of it. Scrum’s entire rhythm depends on the Sprint being a meaningful, resettable unit. For a prototype, it is. For a living codebase, it isn’t. The code doesn’t know it’s a new Sprint.
- Software development is continuous; Sprints are resettable. The codebase persists across every boundary. The “mind reset” Scrum promises is fictional for the actual work.
- Software work isn’t uniform in size. Fixed time-boxes force large and small work into the same mold, producing spillover or padding.
- Bundling unrelated features into a Sprint obscures the real working route and mixes irrelevant work, making planning and implementation messier.
- The Sprint boundary forces false closure — pressure to declare undones as dones.
- Context loss at every boundary. Developers lose the mental model they built, then must rebuild it.
- Ceremony interrupts deep work precisely when developers are most immersed.
A developer forced to “close out” a Sprint and “start fresh” doesn’t get fresh eyes. They get fragmented attention on a system that doesn’t care about the calendar.
4. Framework design flaws
Beyond estimation and rhythm, Scrum has structural design choices that cause trouble in practice. These aren’t implementation mistakes; they’re built into the framework itself. It assumes conditions it can’t create, and it treats engineering as something that will simply emerge from doing the work.
- Scrum fits prototype-shaped work, not continuous work — but presents itself as general-purpose for complex product development.
- No engineering disciplines. Scrum is a work-management framework with no place for architecture, modularity, dependency analysis, or complexity management. Its three artifacts — the Product Backlog, the Sprint Backlog, and the Increment — describe work to be done and work completed, never the structure of the system. Structural coherence therefore depends entirely on factors Scrum doesn’t model.
- No mechanism to distinguish resettable from continuous work. It imposes one rhythm on both.
- Assumes an ideal environment (supportive leadership, aligned incentives) it cannot create, and offers no fallback when absent.
- Its own defenders call it incomplete — “not a complete operating system” — which concedes the gap while excusing it.
The disciplines Scrum leaves out
Scrum left engineering out on purpose. When teams following Scrum started producing working software that decayed — green dashboards on top of crumbling code — the industry reached for a familiar explanation: the team must be missing practices. And so the well-known ones got pulled in: write tests first, integrate continuously, refactor often. These became the standard answer to “Scrum doesn’t cover engineering.”
The problem is that the answer, like Scrum itself, mistakes a technique for a decision. Every choice that determines a system’s long-term health is a judgment about how the system should be shaped and how it will change:
- Where a module boundary goes. Do notifications live inside the user service, or in their own module? This decides what changes together and what can change independently. No test tells you where the line goes.
- Which way dependencies point. Does billing import user, or the reverse? Does the domain layer depend on the database, or the database on the domain? This single decision determines whether a schema change ripples through everything or touches nothing.
- Which abstraction to introduce, and when. Unify three similar code paths too early and you build a wrong abstraction; too late and you copy the same bug three times. This is a bet on what will vary.
- How complexity is contained as the system grows. Someone has to choose a strategy — layers, a dependency rule, a bounded context — and enforce it continuously.
None of these is made by a practice. A passing test suite tells you that behavior still matches expectations inside whatever structure you chose. It cannot tell you the structure is wrong — and by encoding the current design, it can make the wrong structure harder to fix. A suite of passing tests means “still behaves as specified,” not “well designed.” The more tests you write around a bad structure, the more firmly you lock it in.
So the disciplines are not a practice you add to Scrum, or a tool that runs for you. They are decisions, made continuously by people exercising judgment, and neither Scrum nor any practice makes them.
5. Governance and business failures
This is where the damage is most serious, because it affects decisions made with real money. Scrum deliberately abstracts away cost, and that choice has consequences for anyone who has to budget, commit to customers, or allocate capital. The framework doesn’t just fail to help them — it withholds the inputs they need.
- No cost truths. Scrum cannot tell management what the work costs — money, calendar, resources, ROI.
- No reliable schedule. Forecasts are distribution-shifted and say nothing about scope certainty.
- No link between output (points) and value delivered.
- Businesses can’t plan seriously on Scrum’s information alone — so they rebuild the missing planning system outside Scrum, and the two disagree.
- Scrum never replaced the planning system it claimed to obsolete — it just stopped talking about it.
- It blames management for converting points to time while offering no alternative for the planning they must do.
- It abdicates the governance problem and then denies it exists — the most impractical move for a framework sold as practical.
If a business genuinely runs on Scrum’s information alone, it is flying blind on cost and schedule.
6. Organizational and political failures
Even a well-designed framework would collide with organizational reality. Scrum collides hard, because it assumes goodwill and alignment it can’t create. In practice, its tools get repurposed for control, and its ideals become theater.
- Velocity gets used as a performance metric despite the doctrine — because managers are structurally forced to measure output.
- Goodhart’s Law guarantees corruption the moment velocity is tied to reward or pressure: the measure stops measuring.
- It gets industrialized into bureaucracy — certifications, dashboards, “dashboard theatre,” compliance checklists.
- Surveillance disguised as empowerment. Story points and velocity quietly become monitoring tools.
- Self-organization is symbolic. Teams are told they’re autonomous but constrained by external control.
- Management’s role is left ambiguous, producing micromanagers or covert waterfall behind the scenes.
- Cultural mismatch. Scrum requires a paradigm shift most organizations won’t make, so adoption stays superficial — events and artifacts without mindset.
7. The meta-problem
Step back, and a pattern emerges. The problems above aren’t isolated; they share a common move. Scrum identifies real organizational problems, offers a partial fix, and then attributes any remaining failure to the people involved rather than to the framework itself. Both the framework and its common fixes make the same error: treating a technique as a substitute for a decision.
- Scrum exposes organizational flaws rather than fixing them — but presents itself as the solution.
- Friction gets blamed on teams and culture, not on the framework’s shape mismatch.
- It withholds the information decision-makers need, then criticizes them for seeking it.
- Its defenders retreat to “it’s just a framework” when the framework’s own prescriptions cause the damage.
Why this is easy to miss
The mismatch stays hidden in most organizations, and there’s a reason for that. The prototype-shaped slice of software is visible and demoable. A Sprint Review shows a working prototype and everyone applauds. The continuous work — architecture, migrations, technical debt, integration — is invisible, unglamorous, and doesn’t fit a demo.
So the framework looks like it’s working (there’s always something to show) while the continuous substrate quietly rots. The mismatch hides behind the demo.
The honest position
None of this means Scrum is useless. It means Scrum is a specialized tool wearing a general-purpose label.
- Use Scrum for the prototype-shaped work — spikes, proofs of concept, UX exploration, small bounded features — and it will genuinely help.
- Use something else for the continuous work — flow, WIP limits, long-lived context, natural completion boundaries.
- Stop pretending one cadence fits both. The framework can’t tell them apart, so you have to.
And if you’re a manager or owner who needs cost, schedule, and investment truths, don’t expect Scrum to produce them. It was designed not to. Pair it with explicit measurement — cycle time, throughput, delivered value, quality — or you’ll be planning on numbers that were never meant to bear the weight.
The one-sentence version
Scrum is a prototyping methodology mislabeled as a software development framework — it doesn’t fit continuous software work, it doesn’t fit the governance layer that must plan on cost and schedule, and it withdraws from both problems while blaming the people forced to solve them.
What’s your experience? Has Scrum worked for your team’s continuous work, or only for the prototype-shaped parts? Where did the mismatch show up first — estimation, forecasting, or planning?