What is Estimation?
Estimation in product development is the process of predicting how much effort a piece of work will require. Teams estimate to answer a basic question: can we fit this into the next sprint, and when should stakeholders expect delivery?
Common estimation approaches include story points, t-shirt sizing, hours, and ideal days. Each has tradeoffs between precision and speed. The best teams optimize for consistency over accuracy.
Why Estimation Matters
PMs need estimates to make tradeoff decisions. If Feature A is 5 points and Feature B is 13 points, and both deliver similar user value, the choice is obvious. Without estimates, prioritization becomes guesswork.
Estimation also builds team alignment. When engineers discuss whether a task is a 3 or an 8, they surface hidden complexity, missing requirements, and differing assumptions. The conversation matters more than the number.
How to Estimate Effectively
Use planning poker or async estimation to get input from multiple engineers. Divergent estimates signal that the team does not share an understanding of the work. Discuss the gap before converging.
Estimate relative to a reference story. Pick a well-understood past task as your "3-pointer" and compare everything against it. This removes the temptation to convert points to hours.
Track estimate accuracy over time. Compare estimated vs. actual effort each sprint. If you consistently underestimate a certain type of work (API integrations, for example), adjust your reference points.
Estimation in Practice
Basecamp abandoned traditional estimation entirely with Shape Up, using fixed 6-week cycles with appetites instead. The team decides what scope fits the timebox rather than estimating how long scope will take.
At Spotify, squads use relative estimation with Fibonacci sequences. They found that teams who estimate together ship more predictably than teams where a tech lead estimates alone.
Common Pitfalls
- Treating estimates as commitments. An estimate is a forecast, not a promise. Distinguish between "we think" and "we guarantee."
- Estimating alone. A single engineer's estimate misses edge cases. Estimate as a team.
- Anchoring on the first number. In planning poker, reveal estimates simultaneously to avoid anchoring bias.
- Over-decomposing. Estimating 50 subtasks to three decimal places creates false precision. Estimate at the user story level.
Related Concepts
Estimation feeds directly into sprint planning and velocity calculations. Related techniques include story points, t-shirt sizing, and planning poker. For teams that want to move away from estimation, explore the Shape Up methodology.