Few topics generate more heat in the Agile community than estimation. Teams argue about story points vs hours with the intensity usually reserved for tabs vs spaces. Here is a clear-eyed look at the evidence, the trade-offs, and the right answer for your context.
Why Story Points Were Invented
Story points emerged in the early 2000s as a way to separate estimation (complexity and uncertainty) from duration (calendar time). The insight: humans are consistently bad at estimating how long tasks take in hours, but are reasonably good at judging relative complexity. "This story is about twice as complex as that one" is a more reliable estimate than "this story will take 6.5 hours."
Story points also deliberately decouple estimation from individual output. When hours are used, managers compare developer hour estimates — which creates perverse incentives (give low estimates to seem fast, avoid complex work, never revise estimates upward).
The Case For Story Points
| Advantage | Why it matters |
|---|---|
| Relative sizing is more accurate | Teams compare stories to each other, not to an imagined clock |
| Accounts for uncertainty | Fibonacci scale forces acknowledgment that estimates are imprecise |
| Team-level velocity, not individual | Prevents comparison of individual developer productivity |
| Stable across team composition | If one developer leaves, velocity adjusts naturally |
The Case Against Story Points
| Problem | Reality |
|---|---|
| Points are not universal | A 5-point story for Team A might be a 2-point story for Team B — comparison is meaningless |
| Velocity gaming | Under pressure, teams inflate point values to appear more productive |
| Points are not value | Delivering 80 points of low-value features is worse than 20 points of high-value ones |
| Overhead without benefit | Small, experienced teams waste time estimating work that is obviously similar in complexity |
When Hour Estimation Still Makes Sense
- Fixed-price contractual environments where client billing is hours-based
- Single-developer or very small teams where relative sizing adds overhead
- Infrastructure or operations work with well-understood duration patterns
- Post-delivery actuals tracking for billing purposes (not forecasting)
The #NoEstimates Movement
Vasco Duarte's #NoEstimates approach (2012, popularised 2014–2018) proposes eliminating estimation entirely. Instead: break all stories to approximately the same size, track throughput (how many items per sprint), and use Monte Carlo simulation to forecast delivery timelines. For teams with consistent story sizing, this works remarkably well and eliminates the overhead of estimation sessions entirely.
What to Actually Do in 2025
New teams: use story points for 3–6 months to develop relative sizing intuition. Mature teams: transition to throughput-based forecasting if story sizes are consistent. Any team: stop using velocity as a performance metric immediately. CREA-SM's metrics module covers all three approaches and the scenarios in which each is appropriate.