Story points vs hours: which should you estimate in?

Story points estimate the relative size of work — complexity, uncertainty, and effort rolled into one number that only means something relative to your team's other work. Hours estimate absolute time. The instinct is that hours are “more precise,” but precision and accuracy aren't the same thing.

Hours pretend to a certainty the work doesn't have. Points are honest about the fact that you're estimating under uncertainty.

	Story points	Hours
Measures	Relative complexity & uncertainty	Absolute time
Travels across people	Yes (team-relative)	No (varies by who does it)
Drives	Velocity & forecasting	A false-precision schedule
Good for	Sprint planning, forecasting	Short, well-understood tasks; billing
Failure mode	Treated as hours	Brittle when work is uncertain

Why points travel better

A three-point story is a three-point story no matter who picks it up; “four hours” depends entirely on who's doing it and how well they know the code. Points decouple the estimate from the individual, which is why velocity works: the team's point-throughput is stable even as who-does-what shuffles. Hours don't aggregate that way.

The classic mistake is quietly mapping points back to hours (“one point = a day”), which throws away the entire benefit and reintroduces the false precision you were avoiding.

When hours win

Hours aren't wrong — they're right for short, well-understood tasks, for billing, and for anything where the uncertainty is genuinely low. For feature work with real unknowns, points win. Cadenly's Spec workflow sizes each user story in points precisely because it's estimating new, uncertain work — giving you a feel for scope and a basis to sequence the build, without pretending to a schedule it can't honor.