The Fibonacci scale isn’t sacred; it’s just a coarse, non-linear scale that keeps people from pretending to have more precision than they actually have. Any non-linear sequence would work as long as it forces you to acknowledge uncertainty as the numbers grow.

As for “just estimate in time,” the problem is that teams are consistently bad at doing that directly. Mixing “how hard is this” with “how long will it take” collapses two separate variables: intrinsic complexity and local throughput. Story points deliberately avoid that conflation. The team’s velocity is what translates points into time at the sprint level, and that translation only stabilizes if the underlying unit is complexity rather than hours.

The whole point of the method is to strip away the illusion of precision. Time estimates look concrete, but they degrade immediately under uncertainty and project pressure. Relative complexity estimates survive discussion, converge reliably, and don’t invite the fallacy that a complex task with a high risk of surprises somehow has an exact hour count.

That’s why the technique exists. Estimating time directly sounds simpler, but in practice it produces worse forecasts because it hides uncertainty instead of exposing it.