Estimation is one of the most argued topics in Agile communities. The arguments usually go like this: story points versus hours, relative sizing versus absolute, #NoEstimates versus some estimates, planning poker versus whatever came after planning poker.
These are real debates. And they tend to miss the deeper issue — which is that the arguments about how to estimate are standing in for a conversation about whether the estimation model itself is the problem.
What Agile actually said about estimation
Agile didn’t emerge to help teams estimate better. It emerged because someone noticed that in complex work — work where the full requirements can’t be known upfront, where the right approach reveals itself through doing — the precision that estimation promises is false precision.
What “complex work” actually means
That phrase — complex work, work where the full requirements can’t be known upfront — is easy to read past. It shouldn’t be. It’s the most load-bearing claim in this post, and without internalizing it, everything that follows can be heard as an argument about estimation techniques rather than estimation’s fitness for purpose.
Complex work isn’t a description of projects where the team wasn’t smart enough, or rigorous enough, or where the right methodology hadn’t yet been applied. It names a specific category: work where the relationship between cause and effect can only be understood in retrospect. Where the right approach reveals itself through doing, not through analysis. Where requirements change not because stakeholders failed to think carefully upfront, but because doing the work changes what’s needed.
Methodologies — even excellent ones — are built for simple and complicated work. They operate by applying known patterns to known problem types. That’s precisely their value in the contexts they were designed for. Complex work doesn’t have known patterns. It has emergent ones. Applying a methodology to complex work doesn’t solve the problem — it creates the illusion of structure while the actual uncertainty remains untouched. Mini-waterfalls — the short-cycle sequential planning that many Agile implementations quietly became — fall into the same category. The iteration length changes; the underlying assumption that upfront planning can reliably guide the work does not.
“Ruthless simplification” is a related prescription worth examining. If work genuinely can be simplified to a known problem type, simplify it — that’s good practice. But it’s hygiene, not complex work management. What remains after all possible simplification is the part that resists it, which is the complex work itself, requiring something that simplification strategies aren’t designed to provide. If the competitive response to complexity is “we should simplify more,” the conversation about actually managing complex work hasn’t started yet.
Jeffries’ public reversal isn’t just a change of mind about a measurement unit. It’s a recognition of something deeper: the premise was wrong. Estimation assumes a category of work where upfront analysis produces reliable forecasts. For simple and complicated work, that assumption holds reasonably well. For complex work, it doesn’t hold — and no refinement of the technique will make it hold. That realization, once internalized, changes what the rest of this post is about.
A two-week sprint delivering working outcomes isn’t a better estimation method. It’s a replacement for estimation with empirical measurement. Instead of predicting how long work will take, you measure how much actually gets done, under real conditions, in real increments. The prediction gets replaced by a cadence and a feedback loop.
This is not a subtle distinction. It means that teams who run Agile processes but still treat accurate story-point estimation as the goal have fundamentally misunderstood what the process is for.
Why the arguments persist
The estimation debate persists partly because the organizations that adopted Agile didn’t give up their underlying need: management systems built on forecasts, budgets, timelines, contracts. Agile ceremonies got layered on top of that need. Story points became a stand-in for hours. Velocity became a planning input. The Agile vocabulary was adopted; the forecasting expectation was not discarded.
The resulting situation is genuinely contested. Some teams operate in environments where “no estimates” is genuinely possible — where stakeholders have learned to trust empirical delivery and don’t need forecasts. Other teams operate in environments where contracts, regulatory requirements, or organizational culture make some form of forecasting unavoidable.
The Agile position is not that estimation is always wrong. It’s that estimation in complex work is structurally unreliable — that the confidence attached to estimates regularly exceeds the evidence for them — and that the discipline of short delivery cycles with real feedback does more to improve predictability than better estimation methods do.
The units problem — and a pattern worth noticing
A current trend in Agile circles is moving away from story points toward Ideal People Days (IPDs) — a return to time-based estimation that its proponents argue is more intuitive and easier to defend to stakeholders.
It’s worth knowing where story points came from. Ron Jeffries — one of the three founders of Extreme Programming and an original Agile Manifesto signatory — invented story points. They emerged directly from ideal days, the time-based unit XP teams originally used. The problem with ideal days was that stakeholders heard “three ideal days” and interpreted it as a three-day commitment, regardless of the “ideal” qualifier. So the time label got stripped away, and the raw number became the unit. Story points were, in origin, ideal days with the time reference removed specifically to prevent them from being treated as time commitments.
Jeffries has since written about this directly. “I like to say that I may have invented story points,” he wrote in 2019, “and if I did, I’m sorry now.” He is now among the most prominent advocates for #NoEstimates — the position that the problem isn’t which estimation unit you use, but that estimation in complex work is fundamentally unreliable regardless of unit.
It’s worth asking why the move to IPDs is happening now. The answer is not that teams have found a better estimation method. It’s that IPDs align with Waterfall financial infrastructure — the budget cycles, project accounting systems, contract billing models, and headcount planning tools that organizations built around time-based planning and never changed when they adopted Agile. Story points don’t slot into those systems. IPDs do.
This isn’t companies finally taking charge and correcting what Agile missed. It’s companies reasserting the infrastructure that never changed — using financial structures that were never dismantled to pull practice back toward the model they were built to support. IPDs require no shift in mind, understanding, or thinking — you simply re-label what you already know. The estimation unit changes; the organizational system demanding time-based commitments does not. The result is the same forecasting theater, just with a new name. That’s precisely why they’re gaining ground.
The Agile community missed a leadership opportunity here. When the demand for time-based forecasts returned dressed as IPDs, the right response was to name what was happening: this is Waterfall finance reasserting itself over Agile practice. Instead, many practitioners accommodated it, treating the demand as a constraint to manage rather than a category error to correct. The result is that the teams most fluent in Agile vocabulary are often running the most sophisticated version of the model that Agile was designed to replace.
Humanity learns slowly
There is a pattern here that goes deeper than estimation methodology. It is the pattern of treating a label change as a practice change — of mistaking the adoption of new vocabulary for the shift in thinking that vocabulary was supposed to represent.
Einstein’s definition of insanity is often quoted, usually misattributed, but reliably resonant: doing the same thing over and over and expecting different results. The attribution is probably a widely repeated story whose origins are unclear. The pattern is not. Organizations that adopted Agile ceremonies without adopting Agile thinking are now adopting Agile’s replacement ceremonies without examining whether the underlying thinking has changed. The words are different. The model is the same.
The conversation this post is trying to open isn’t about estimation units. It’s about whether your organization has genuinely reckoned with what complex work is and what it requires. If the answer is that your planning infrastructure hasn’t changed — that you still need forecasts, commitments, and time-based accounting that assume upfront analysis produces reliable predictions — then the estimation debate is a symptom. The condition it points to is that the shift Agile was proposing hasn’t happened yet.
Comments 0