You're in sprint planning. Someone pulls up a ticket: "Add password reset flow."
The team discusses. "That's probably a 5," someone says. "Maybe an 8 if we hit edge cases."
You settle on 5. Everyone nods. The ticket gets added to the sprint.
Two weeks later, that 5 point ticket is still in progress. It turned out the email service needed upgrading. Then rate limiting became an issue. Then someone found a security concern.
The 5 turned into a 13. And everyone's surprised, even though this happens every sprint.
Why do we keep pretending our estimates are accurate?
The Estimation Theater
Here's what we know about estimates:
- They're almost always wrong
- They're more wrong the further out you go
- Uncertainty compounds across dependencies
- The act of estimating doesn't make the work faster
And yet, we spend hours in planning meetings debating whether something is a 5 or an 8. We calculate team velocity. We forecast release dates based on story points.
We build elaborate systems on top of guesses.
Why We Do It Anyway
The honest reason? Estimates make us feel in control.
Stakeholders want to know when things will be done. Managers want to forecast capacity. Teams want to know if they're "on track."
Estimates give the illusion of predictability. They let us say "we'll ship this in 6 weeks" with confidence, even though we have no idea if that's true.
Estimates are a security blanket. Not for the team, but for everyone around them.
The Planning Fallacy
Humans are terrible at estimating. We consistently underestimate how long things will take, even when we know we tend to underestimate.
Why? Because we estimate based on the ideal path. We assume:
- No surprises
- No dependencies
- No context switching
- No bugs
- No scope creep
We estimate the best case and call it the expected case.
Then reality happens. And we act shocked when the estimate was wrong, even though it's wrong every time.
What Actually Helps
If estimates are always wrong, what should we do instead?
1. Estimate in ranges
Instead of "5 points," say "between 3 and 8." Acknowledge the uncertainty upfront.
2. Break things down
Small tasks are easier to estimate. Instead of estimating "build authentication," estimate "add login form," "add password validation," "add email verification" separately.
3. Track actual time
Once you finish something, note how long it actually took. Over time, you'll get better at seeing patterns in your wrongness.
4. Stop forecasting far out
Estimating the next few days is possible. Estimating three months from now is fiction. Plan short, adjust often.
5. Use estimates for prioritization, not deadlines
Estimates are useful for deciding what to work on next. "This is big and uncertain, let's tackle it early." They're not useful for promising delivery dates.
The Radical Alternative
Some teams skip estimation entirely. They just work on whatever's most important until it's done. No points. No velocity. No forecasting.
Sounds chaotic, right? But here's what happens:
- They spend less time in planning meetings
- They don't feel guilty when estimates are wrong
- They focus on making tasks small and shippable
- They communicate progress through working software, not story points
They trade the illusion of predictability for actual agility.
The Honest Conversation
If you're going to estimate, at least be honest about it:
"This is our best guess. It's probably wrong. We'll know more as we dig in. We'll keep you updated."
No false precision. No velocity forecasts based on imaginary math. Just: here's what we think, but we might be wrong.
Because pretending estimates are accurate doesn't make them accurate. It just means no one's surprised when you miss the deadline.
Stop pretending. Start acknowledging uncertainty. Plan accordingly.
✨
Ready to try Bonjour?
A hyper-focused feed for your team. No endless lists. Just the work that matters.