Story points are a unit used by Scrum teams to estimate the relative effort required to complete a backlog item. The critical word is relative. Story points are not hours. They are not days. They are not a prediction of how long something will take. They are a measure of complexity and effort compared to other items the team has estimated.

This distinction matters because it changes what story point estimation is for and how it should be used.

What story points measure

Three factors typically inform a story point estimate: the effort required to complete the work, the technical complexity involved, and the uncertainty or risk around what is not yet understood. A story that is well-understood, technically straightforward, and involves no surprises might be estimated at 2 points. A story that involves significant complexity, multiple unknowns, and touches systems nobody has worked with recently might be estimated at 13 points.

What the absolute values mean is less important than their relationship to each other. Story points provide a consistent relative scale — a 5 is roughly 2.5 times the size of a 2, whatever the team's 2-point stories look like in practice. This consistency is what makes velocity — the average story points completed per Sprint — a useful planning input.

The Fibonacci sequence

Most teams use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34...) for story point values. This is not arbitrary. The gaps between Fibonacci numbers grow as the numbers get larger, which reflects an honest truth about estimation: the uncertainty in a 13-point estimate is much larger than the uncertainty in a 3-point estimate. Using a scale where the gaps grow forces teams to acknowledge this uncertainty explicitly rather than creating false precision.

Items estimated at 13 points or above are usually candidates for decomposition — not because they cannot be delivered, but because large, complex stories tend to have hidden sub-problems that only become visible when the work is broken down. Smaller, more granular stories produce more accurate estimates and more predictable Sprints.

Planning Poker

Planning Poker is the most widely used estimation technique in Scrum teams. The process is straightforward: the Product Owner presents a user story, the team discusses it and asks clarifying questions, and then each team member privately selects a card representing their estimate. All cards are revealed simultaneously.

The simultaneous reveal is the essential feature. It prevents anchoring — the cognitive bias where people adjust their estimates toward the first number they hear, regardless of their independent assessment. When everyone reveals at the same time, the conversation that follows is genuinely informative: why did one developer estimate 3 and another estimate 13? The answer almost always reveals either different understanding of the story or different awareness of technical complexity that others in the room need to hear.

The process repeats until consensus is reached — usually within two or three rounds. The estimate is not the point; the conversation is.

What story points are not

Story points are not a time estimate, and treating them as one consistently produces bad outcomes. The velocity-based planning process — using historical average story points per Sprint to forecast future delivery — is only valid if story points remain genuinely relative and are not being influenced by time pressure or external commitments.

Story points are not a performance metric. Comparing velocity between teams, or tracking individual contributions in story points, corrupts the estimation process. When points become a measure of output rather than a planning input, teams optimise for the number rather than for honest assessment of complexity.

Story points are also not mandatory. Some mature teams move to throughput-based forecasting — using the number of items completed per Sprint rather than story points — which avoids the overhead of estimation while providing equally useful planning data. The Kanban Method provides the framework for this approach. Both are valid; the right choice depends on the team's context and what their planning process actually needs.