Software Engineering
Estimation and Planning
NASA lost the Mars Climate Orbiter in 1999 due to a $327 million mistake - one team calculated in metric units, another in imperial. Nobody clarified assumptions. Estimation is not about numbers. It is about synchronizing understanding.
- **Spotify** measures squad velocity in SP for quarterly OKR planning - but never compares SP across teams, since each team calibrates independently.
- **Basecamp** replaced estimates with 'appetite' - teams decide how much time a feature is worth and stop when the budget is spent, rather than extending deadlines.
- **Amazon** uses T-Shirt Sizing at the PR/FAQ stage (before any code): initiatives are ranked S/M/L to filter out XL-monster ideas early.
Story Points
Story Points are a relative measure of complexity, effort, and uncertainty in a task - not hours. A task rated 5 SP is roughly twice as hard as a task rated 2 SP, but says nothing about calendar time.
Velocity is team-specific and non-transferable. Comparing SP across teams is meaningless - each team calibrates relative to their own baseline.
Story Points measure how long a task takes
Story Points measure relative complexity and uncertainty. Time is estimated separately via velocity, which emerges from historical data.
Treating SP as hours causes anchoring bias: estimates are influenced by available time rather than actual complexity.
A team estimates a task at 13 SP. What does this mean?
T-Shirt Sizing
T-Shirt Sizing uses XS/S/M/L/XL labels to quickly categorize work items at the roadmap or initiative level - before detailed sprint planning begins.
T-Shirt Sizing sacrifices precision for speed. It is the right tool when comparing options, not when committing to a sprint.
When is T-Shirt Sizing preferable to Story Points?
#NoEstimates
#NoEstimates is a movement that replaces effort estimates with throughput measurement. Instead of asking 'how long will this take?', teams ask 'how many tasks do we complete per week?' and use that rate to forecast delivery.
The core insight: when stories are similarly sized, count is a better predictor than estimation. Estimation sessions are replaced by continuous decomposition.
What is the foundation of forecasting in the #NoEstimates approach?
Planning Poker
Planning Poker is a consensus-based estimation technique where all participants reveal their estimates simultaneously. The value is not in the numbers - it is in the discussion that follows when estimates diverge.
When estimates converge (everyone picks 5), the session is fast. When they diverge (3 vs 13), the divergence itself is the value - it surfaces assumptions that were invisible before.
Planning Poker is a waste of time - just ask the most experienced developer
Collective estimation surfaces hidden assumptions and misaligned understanding that a single expert cannot detect alone.
When estimates diverge 3x or more, it reliably indicates an unstated assumption or scope disagreement. That discussion, before the sprint begins, prevents scope creep and missed deadlines.
Why do Planning Poker participants reveal cards simultaneously?
Summary
- **Story Points** measure relative complexity, not time - team velocity builds forecasts from accumulated historical data.
- **T-Shirt Sizing** (XS/S/M/L/XL) is the right tool for quickly prioritizing a large backlog at the roadmap level, not at the sprint level.
- **#NoEstimates** replaces SP with throughput measurement (tasks/week) - this works when stories are decomposed to roughly equal size.
- **Planning Poker** is valuable not for consensus, but for the discussion when estimates diverge - it synchronizes understanding before work begins.
Related Topics
Estimation is inseparable from delivery processes and team dynamics:
- Kanban and Lean — Kanban metrics (cycle time, throughput) are the foundation of the #NoEstimates approach.
- Technical Leadership — Tech leads facilitate Planning Poker and are responsible for realistic estimates in front of stakeholders.
- CI/CD Pipeline — Pipeline speed directly affects team velocity - slow builds reduce the number of stories completed per sprint.
Вопросы для размышления
- What estimation method does the current team use? How accurate do estimates turn out to be in practice?
- Have there been cases where different team members estimated the same task wildly differently? What did the divergence reveal?
- If the team switched to #NoEstimates - what would change in sprint planning and communication with stakeholders?