Glossary
By Glue Team
Estimation best practices are proven frameworks and techniques for predicting how long software development tasks will take. They move estimation away from gut feeling toward data-driven assessment, using codebase metrics, historical patterns, and task complexity to forecast timelines with higher accuracy.
Studies show that software estimates are wrong by default: projects exceed estimates by 23-66% on average. Why?
Estimation best practices solve this by grounding forecasts in actual code metrics.
Story point estimation: Relative sizing based on complexity, not time. A 2-pointer is twice as hard as a 1-pointer, but doesn't necessarily take 2x hours (accounting for parallel work, interruptions, reviews). Works best when coupled with historical team velocity.
Three-point estimation: Collect optimistic, most-likely, and pessimistic estimates, then calculate weighted average. Reveals assumptions and reduces overconfidence bias.
Complexity-based estimation: Size tasks by measuring cyclomatic complexity, file dependencies, and test coverage of affected code. Teams that estimate based on codebase metrics are 40% more accurate.
Velocity-based forecasting: Track how much work a team completes each sprint, then project future sprints. Works only if velocity is consistent and accounting for known disruptions.
Estimate in relative terms first, not absolute hours. Humans are better at comparison than absolute prediction.
Break tasks small. Anything over 13 story points should be split; larger tasks hide unknowns.
Include exploration time. If an engineer says "3 days," add 50% buffer for learning, debugging, and unforeseen issues unless they're extremely familiar with that code.
Account for dependencies. If a task depends on another's completion, serial work takes longer than parallel. Map dependencies explicitly.
Use historical data. If similar tasks took 5 days in the past, a 20% larger task likely takes 6 days—not a guess.
Adjust for code health. Estimates in legacy codebases should be 1.5-2x higher than in well-structured code. Make technical debt visible in estimates.
Re-estimate if context changes. New team member? Refactoring required? Estimate again; context shifts accuracy.
Q: Should we use story points or hours? A: Story points are more accurate because humans are better at relative sizing. Hours work only with very detailed historical data and consistent conditions.
Q: How do we estimate refactoring work? A: Treat refactoring like any task: measure complexity before/after, estimate based on codebase data, and include testing time. Refactoring is often underestimated because hidden dependencies emerge during work.
Q: What if estimates are always wrong? A: That's normal. Focus on calibration: if 50% of estimates miss by 30%, aim to miss by 25% next sprint. Improving accuracy by 10% over a year is a major win.
Keep reading
