There's a persistent myth that Scrum requires story points, or that estimation is a core, non-negotiable pillar of the framework. Neither is true, and the confusion is worth clearing up, because it shapes how teams think about a genuinely optional practice.
What the Scrum Guide actually says
The Scrum Guide, in its current form, doesn't mandate any specific estimation technique. It doesn't require story points, doesn't require Planning Poker, and doesn't even require that Product Backlog items be estimated in a formal numeric sense at all. What it requires is that the Development Team has enough shared understanding of the work to make a reasonable forecast about what can be delivered in a sprint. How that understanding gets built is left to the team.
This matters because a lot of what teams treat as "Scrum requires this" is actually "a popular implementation of Scrum does this." Story points, velocity tracking, and Fibonacci-sequence estimation scales are widespread practices that emerged from the broader agile community, not requirements written into the framework itself.
Why estimation exists at all
Estimation serves a genuinely useful purpose when it's used for planning conversations rather than as a performance metric: it forces the kind of discussion that surfaces hidden complexity before work starts, rather than mid-sprint. A team disagreeing about whether a story is a 3 or an 8 is often really disagreeing about what the story actually requires, and the estimation exercise is what surfaces that disagreement early enough to resolve it cheaply.
The problem is what happens when estimates stop being a planning tool and start being treated as a commitment or a performance measure. Once velocity becomes a number that management tracks and compares across sprints or teams, the incentive shifts from "estimate accurately to plan well" to "estimate in whatever way makes the number look good," and the entire practice quietly stops doing its original job.
Relative estimation versus absolute estimation
Where teams do estimate, relative estimation, sizing work against other work rather than against absolute time units, tends to hold up better than absolute estimation in hours or days. Humans are demonstrably bad at estimating absolute duration for unfamiliar work, but reasonably good at comparative judgments ("this is roughly twice as complex as that other thing we did"). This is the actual argument for story points over hour-based estimates, and it's a real one. It's just not a Scrum requirement, it's a response to a well-documented cognitive limitation.
The alternative some teams are moving toward
A growing number of teams skip estimation altogether in favor of breaking work down small enough that most items are roughly similar in size, and tracking throughput (how many items get completed per sprint) instead of story points. This trades the upfront estimation conversation for a discipline of aggressive backlog decomposition, and for teams that do the decomposition well, it removes an entire category of debate without losing the planning value that estimation was meant to provide.
Neither approach is more "correct" Scrum than the other. The framework is silent on the question by design, leaving the choice to whichever approach actually serves a given team's need to plan and forecast its work.