By Arjun Mehta
Estimates are wrong. Always. You estimate a feature at 3 weeks, it takes 5. You estimate 2 weeks, it takes 10 days. Sometimes you're lucky. Mostly you're not.
The question isn't whether estimates are wrong. It's why they're wrong and what to do about it.
Why Estimates Are Wrong
1. You don't know what you don't know. When you estimate, you estimate based on current knowledge. But you don't find bugs until you write the code. You don't find architectural constraints until you implement. You don't discover integration complexity until you try to integrate.
Estimates are always based on incomplete information. New information arrives during implementation. Estimates change.
2. Unknowns compound. A feature touches five systems. You estimate each at 1 week. Total: 5 weeks. But you didn't account for integration complexity. Now it's 7 weeks. You didn't account for testing. Now it's 9 weeks. Unknowns compound exponentially.
3. Interruptions destroy plans. You estimate 5 weeks for Feature A. Your estimate assumes 40 hours per week of uninterrupted time. But your engineer gets paged for production issues. Handles customer escalations. Attends meetings. They get 25 hours per week of real coding time. Now Feature A takes 8 weeks.
4. Humans are optimistic. Psychologically, we're biased toward optimism. We estimate best-case scenarios. Experienced engineers add buffer. But even experienced estimators are 20-30% low on average.
The Mathematics of Wrong Estimates
Consider a feature with three components:
- Component A: 2 weeks (actually 3, 50% wrong)
- Component B: 1 week (actually 1.5, 50% wrong)
- Component C: 2 weeks (actually 2.5, 25% wrong)
Estimate: 5 weeks. Reality: 7 weeks. 40% wrong.
Now add integration: +1 week estimated, +2 weeks actual. 5 vs 7.
Estimate: 5 weeks + 1 week = 6 weeks. Reality: 7 + 2 = 9 weeks. 50% wrong.
With multiple components and unknowns, your error rate compounds. Estimates for large features are often 50-100% wrong.
For small features (1-2 days), estimates are usually within 25%. For big features (multiple weeks), estimates are often 50%+ wrong.
How To Estimate Better
You can't estimate accurately. But you can be less wrong.
1. Estimate Small
Break features into smaller chunks. Instead of "implement checkout: 4 weeks," break it into:
- Shopping cart functionality: 1 week
- Payment integration: 2 weeks
- Order confirmation: 1 week
Smaller estimates are more accurate. A 1-week estimate is usually within 25%. A 4-week estimate is often 50%+ wrong.
Why? Because small estimates have fewer unknowns. Fewer things can go wrong.
2. Add Explicit Buffer
If an estimate is 3 weeks, that's based on the happy path. Add buffer for unknowns. Maybe 25-50% depending on how uncertain you are.
Estimate: 3 weeks. Buffer: 1 week. Total commitment: 4 weeks.
Better to commit to 4 and deliver in 3.5, than commit to 3 and deliver in 5.
3. Track What Actually Happens
After a feature is done, compare estimate to reality. "We estimated 4 weeks, delivered in 5.5 weeks. What did we miss?"
Pattern emerges. Maybe you always underestimate integration. Now you know: add 20% buffer for integration.
4. Understand Your Sources of Error
Where do estimates go wrong?
- Testing? (Always takes longer than estimated)
- Integration? (Systems interact unexpectedly)
- Unknowns? (Architecture changes mid-implementation)
- Interruptions? (Production fires, support)
- Rework? (Doesn't meet acceptance criteria first time)
Once you know your sources of error, you can account for them in future estimates.
5. Estimate Ranges, Not Points
Instead of "3 weeks," say "2.5 to 4 weeks."
Range estimates acknowledge uncertainty. They're more honest. And they're more likely to be right (range contains the actual time more often than a point estimate).
Better yet: estimate optimistic (2.5 weeks), pessimistic (4 weeks), and most likely (3 weeks). That gives leadership different scenarios.
Why Estimation Matters
When estimates are wrong, plans go wrong. You commit to shipping Feature A and B in Q2. Estimate was wrong. Now you can only ship Feature A. Feature B slips. Your roadmap becomes fiction.
Customers lose confidence. Leadership loses confidence. Your team internalizes that planning doesn't matter.
Better estimates mean better planning. Better planning means more predictable delivery. More predictability means more trust.
Using Glue to Estimate Better
When you don't understand your codebase, estimates are based on guesses. With Glue, you can understand what's already built, where architectural constraints are, and what kind of rework is needed.
Better understanding of your codebase means better estimates.
Frequently Asked Questions
Should we just pad all estimates by 50%? No. That's hiding the problem, not solving it. If you pad everything by 50%, soon people pad by 50% of that, and the padding becomes meaningless. Better: estimate accurately and add explicit buffer for unknowns.
How do we explain wrong estimates to leadership? Honestly. "We estimated 4 weeks, we're running 6. Here's what we missed." Leadership appreciates honesty. They hate surprises.
Is estimation just guessing? Partially. But informed guessing is better than random guessing. Track your estimates. Learn from misses. Improve.