Every Wednesday at 2 PM, twelve developers file into a conference room. For the next ninety minutes, they'll 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 dirty secret: all those story points, all that calibration training, all those hours in planning poker—none of it makes your estimates more accurate.
The Hidden Costs
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.
For an eight-person team over a year: 1,664 to 2,496 hours—the equivalent of one full-time engineer doing nothing but estimation work.
Why Calibration Training Won't Help
The estimation industrial complex has an answer when your estimates prove wildly inaccurate: you need better calibration.
It's sophisticated-sounding bullshit.
Real developers reveal the truth: even when teams track velocity religiously and conduct elaborate calibration exercises, estimates remain wildly inaccurate.
This isn't a failure of discipline. It's because 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, and emergent complexity that only appears when components interact.
Working Without Estimates
The grown-up response to estimation failure isn't better estimation. It's acknowledging that for complex knowledge work, estimates provide false precision.
Slice Work Into Deployable Increments
Stop trying to estimate large features. Break work into the smallest deployable piece that delivers any value.
Not: "Rebuild the notification system - 40 points"
Instead:
- "Send email when 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. Each piece delivers value. Each piece takes days, not weeks.
Track Flow Metrics, Not Velocity
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: How many items in flight simultaneously?
These metrics are actual data, not subjective points.
Budget Time, Not Scope
For 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.
The Uncomfortable Truth
Management wants certainty. Estimation theater gives them the illusion without the 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 they're more respectful of everyone's time than pretending story points solve the prediction problem.
Start Small, Start Now
You don't need permission to stop wasting time in estimation ceremonies.
Start with your team. Propose an experiment: one sprint without estimates. Just priority order and cycle time.
Track what happens. Measure throughput. Measure time saved.
My prediction: throughput stays the same or improves. Stakeholder satisfaction stays the same or improves. Developer satisfaction definitely improves.
Because you've eliminated theater and replaced it with actual work.
Stop pointing stories. Start shipping software.
Full article with practical transition checklist at AgileLie.com
Top comments (1)
Funny coincidence — your article feels like it naturally extends a point I explored recently. Mine looks at “Agile theater” from a broader angle, and yours dives into one of its most visible symptoms: estimation rituals.
It reads almost like a parallel chapter of the same story, each covering a different layer. And honestly, putting both perspectives side by side makes the whole picture clearer.