Every engineering manager has lived this: "How long will this take?" followed by a confident answer that turns out to be wrong by 2-5x.
The problem isn't that engineers are bad at estimating. The problem is that software estimation is fundamentally hard, and most teams use methods that make it harder.
Why Estimates Are Always Wrong
Unknown Unknowns
You can estimate the work you can see. You can't estimate the work you'll discover along the way: the legacy code that doesn't work like the docs say, the API that has undocumented rate limits, the database migration that reveals data inconsistencies.
In a typical feature implementation, 30-50% of the work is discovered during the work. Any upfront estimate misses this by definition.
Anchoring Bias
The first number mentioned becomes the anchor. If a PM says "I was thinking 2 weeks," the estimate gravitates toward 2 weeks regardless of actual complexity. If the tech lead says "probably a sprint," everyone adjusts from there.
Parkinson's Law
Work expands to fill the time allocated. Give a team 2 weeks and they'll take 2 weeks. Give them 3 weeks and they'll take 3 weeks. The estimate becomes a self-fulfilling prophecy, but not always a correct one.
Knowledge Gaps
The person giving the estimate often doesn't have full understanding of the system they're estimating changes to. Tribal knowledge means the real complexity is hidden in someone else's head. The estimate reflects the visible complexity, not the actual complexity.
What Actually Works
1. Reference-Class Forecasting
Instead of estimating from scratch, look at similar past work:
- "The last 5 API endpoints we built took 3-7 days each"
- "Database migrations in this codebase have historically taken 2x our estimate"
- "Integration with external APIs has never taken less than 2 weeks"
Your past delivery data is the best predictor of future delivery.
2. Thin-Slice Delivery
Instead of estimating a 6-week project and hoping you're right, break it into 1-week deliverable slices. Ship the first slice. Re-estimate based on what you learned.
This is why high deployment frequency correlates with better outcomes — small batches give you faster feedback on your estimates.
3. Understand the Codebase First
Half the reason estimates are wrong is that engineers don't understand the full complexity of the code they'll need to change. The dependency graph, the bus factor (can you even get help if you're stuck?), the code health of the area you'll be working in.
Codebase intelligence tools can surface this context before you estimate — showing you the blast radius, ownership map, and historical change patterns for the area of code involved.
4. Ranges, Not Points
"3 weeks" is a point estimate and is almost certainly wrong. "2-5 weeks, most likely 3" gives the PM what they actually need: a range for planning, a best case, and a worst case.
5. Track Accuracy
Measure how accurate your estimates are over time. If you consistently estimate 1 week and deliver in 2, you have a systematic 2x bias. Correct for it.
The Real Problem
The real problem isn't estimation — it's that organizations use estimates for the wrong thing. Estimates should be planning inputs, not commitments. When an estimate becomes a deadline, engineers pad defensively, managers pressure for smaller numbers, and the whole system produces unreliable information.
The best teams I've worked with don't argue about estimates. They ship small batches, measure throughput, and use historical data to forecast. No guessing. No negotiation. Just data.
Originally published on getglueapp.com/glossary/software-project-estimation
Glue helps teams understand codebase complexity before estimating — surfacing dependencies, knowledge concentration, and historical change patterns.
Top comments (0)