Why Your Estimates Keep Being Wrong (And How to Fix It)
Occasional estimation misses are normal. Consistent misses in the same direction are a signal that something structural is broken. Here's how to find it.
Consistently underestimating
Probable cause: hidden work isn't being counted
Common culprits: code review time, writing tests, deployment steps, documentation, waiting for QA sign-off. When teams estimate only the core development work, they miss 30-50% of what "done" actually requires.
Fix: Audit a few recent stories. Map everything that happened between "started" and "accepted." Add those activities to your Definition of Done and let them influence future estimates.
Consistently overestimating
Probable cause: overconfidence in worst-case scenarios
Some teams have been burned before and systematically pad every estimate as self-protection. The result is consistent under-delivery against capacity: the team has more room than it used and stakeholders wonder why.
Fix: Run a retrospective on five stories you overestimated. Were the risks you guarded against actually present? If not, your priors need updating.
Wide variance (sometimes right, sometimes wildly wrong)
Probable cause: unclear acceptance criteria
Stories with vague scope produce inconsistent estimates because each developer imagines a different scope. The estimate is often "correct" - for whatever version of the story they imagined.
Fix: Add a Definition of Ready that requires acceptance criteria before a story enters estimation.
Estimates right, time wrong
Probable cause: external dependencies
A story might be genuinely 3 points of development work but take two weeks calendar time because of an external API provider, a legal review, or another team's deliverable.
Fix: Track blocked time separately from active development time. Estimates shouldn't account for wait time you can't control.
Estimation is a feedback loop. Every sprint is data. If you're not reviewing misses systematically, you're running the loop without reading the output.