Why Agile Estimation Is Theater (And What To Do Instead)
Source: Dev.to
Introduction
Every Wednesday at 2 PM, twelve developers file into a conference room. For the next ninety minutes they hold up cards with Fibonacci numbers, debate whether a feature is a 5 or an 8, and pretend they can predict how long work will take in a system that changes daily.
This is your modern Agile estimation ceremony. It’s theater. And everyone knows it.
The Problem with Estimation
The dirty secret: all those story points, all that calibration training, all those hours in planning poker—none of it makes your estimates more accurate.
Cost of Estimation
A typical two‑week sprint for an eight‑person team:
- 90‑minute backlog refinement
- 2‑hour sprint planning with estimation
- 30 minutes re‑estimating carry‑over work
- 15 minutes per story for clarification
That’s 4–6 hours per sprint per developer. Over a year, an eight‑person team spends 1,664 – 2,496 hours—the equivalent of one full‑time engineer doing nothing but estimation work.
Why Estimates Remain Inaccurate
Even when teams track velocity religiously and conduct elaborate calibration exercises, estimates stay wildly inaccurate. This isn’t a failure of discipline; accurate software estimation is mathematically impossible for complex work.
You’re estimating in a system with:
- Incomplete information about requirements
- Unknown technical dependencies
- Constantly changing codebases
- Integration points that fail in novel ways
- Emergent complexity that only appears when components interact
A Different Approach
The grown‑up response to estimation failure isn’t “better estimation.” It’s acknowledging that for complex knowledge work, estimates provide false precision.
Break Work into Small Deployable Pieces
Don’t: “Rebuild the notification system – 40 points”
Do:
- “Send email when a user’s post gets first comment – ship it”
- “Add email preference toggle – ship it”
- “Support digest mode instead of immediate – ship it”
Each piece ships to production, delivers value, and takes days, not weeks.
Measure What Matters
Stop measuring story points delivered. Start measuring:
- Cycle time: How long from starting work to production?
- Throughput: How many items completed per week?
- Work in progress (WIP): How many items are in flight simultaneously?
These metrics are actual data, not subjective points.
Managing Larger Initiatives
Flip the question. Instead of “How long will this feature take?” ask “What can we deliver in 4 weeks?”
- Time‑box the work.
- Define the problem and success metrics.
- Work iteratively, shipping progressively better solutions until the time box expires.
Honest Conversations with Management
Management wants certainty. Estimation theater gives them an illusion without substance. When you abandon estimates, you’re forced to have harder, more honest conversations:
“We can’t promise this will ship by June. We can promise we’ll work on nothing else until it ships, and we’ll deploy increments weekly so you see progress.”
These conversations feel uncomfortable because they expose the irreducible uncertainty in software development, but they’re honest and more respectful of everyone’s time than pretending story points solve the prediction problem.
Experiment Proposal
You don’t need permission to stop wasting time in estimation ceremonies.
- Propose an experiment: one sprint without estimates—just priority order and cycle time.
- Track what happens.
- Measure throughput, time saved, and stakeholder satisfaction.
Prediction: Throughput stays the same or improves, stakeholder satisfaction stays the same or improves, and developer satisfaction definitely improves. You’ve eliminated theater and replaced it with actual work.
Conclusion
Stop pointing stories. Start shipping software.
Full article with practical transition checklist at AgileLie.com.