Estimation Is a Conversation, Not a Commitment
Every time a team gives an estimate and a manager writes it in a project plan, a small act of organizational violence occurs. The estimate becomes a deadline before any work has begun.
The failure mode is familiar: a developer says "probably two weeks," a project manager hears "two weeks," a stakeholder hears "two weeks maximum," and an executive communicates "shipping in two weeks" to a client. The estimate has traveled through four layers of organizational telephone and emerged as a contractual obligation. When the work takes three weeks — as it often does, because estimates are probabilistic, not deterministic — the developer is blamed for missing a commitment they never made.
What estimation is actually for
Estimation serves two legitimate purposes: facilitating conversation about scope and complexity, and enabling rough capacity planning at the portfolio level. It does neither of these things well when estimates are treated as promises. The planning poker session where a team debates whether a story is a 3 or a 5 is valuable not because of the number produced — but because the disagreement surfaces different understandings of scope that need to be resolved before work begins. The number is a byproduct. The conversation is the product.
The #NoEstimates movement has a point
The #NoEstimates movement — which advocates replacing story point estimation with throughput-based forecasting — has attracted significant criticism for being impractical in contract-driven environments. But its core insight is sound: if you have enough historical data on how long similar work takes, you can generate probabilistic forecasts that are more accurate than individual estimates and require far less ceremony to produce. Many teams are better served by tracking their throughput and using Monte Carlo simulation for forecasting than by spending hours in estimation sessions.
The practical middle ground
For most teams, the healthiest approach is relative sizing (T-shirt sizing or story points) used for sprint planning and backlog prioritization, combined with explicit communication about what estimates mean: "This is our best guess based on current understanding. It will change as we learn more." Teams that internalize this framing — and have stakeholders who accept it — spend less time re-estimating and more time delivering.
Ready to put this into practice?
Join a SAFe certification course and master agile at scale.
Browse Courses →
