Estimation is one of the most discussed and most misunderstood parts of Scrum. Teams spend significant time on it, debate it at length, and often find that the estimates they produce bear a loose relationship to how long things actually take. This leads some teams to abandon estimation entirely. It leads others to double down on precision in ways that produce false confidence rather than useful information.

Neither response is well-calibrated. The purpose of estimation in Scrum is not to predict accurately — it is to think through complexity, surface unknowns, and build a shared understanding of what the work involves. Those things are valuable regardless of whether the final number turns out to be right.

What estimation is actually for

During Sprint Planning, the team uses estimates to make a realistic assessment of what they can commit to within the Sprint. The estimate is not a promise — it is a reasoned forecast based on the team's current understanding of the work. When actual delivery differs from the estimate, that is information about the work and about the team's understanding of it, not a failure of discipline.

Estimates also support prioritisation. Items that are significantly larger than expected may warrant decomposition before they enter a Sprint. Items that prove much simpler than estimated may reveal opportunities to take on additional work. The estimate is a planning input, not a contract.

Story points and the Fibonacci sequence

Most Scrum teams estimate in story points — a relative measure of complexity rather than a direct time estimate. The Fibonacci sequence (1, 2, 3, 5, 8, 13, 20...) is commonly used for the values because the gaps between numbers grow as the numbers get larger, which reflects a practical truth: the uncertainty in an estimate of 20 points is much greater than the uncertainty in an estimate of 3 points, and pretending otherwise produces false precision.

The team's velocity — the average number of story points completed per Sprint — provides the basis for Sprint planning. Rather than estimating time for each item, the team uses velocity to assess whether the selected items are feasible within the Sprint timebox.

Planning Poker

Planning Poker is the most widely used estimation technique in Scrum teams and for good reasons. The process is straightforward: the Product Owner presents a user story, the team asks clarifying questions until they understand what is being asked for, and then each team member privately selects a card representing their estimate. All cards are revealed simultaneously.

The simultaneous reveal is the crucial element. It prevents anchoring — the tendency for people to be influenced by the first estimate they hear. When all estimates are visible at the same moment, the discussion that follows is grounded in genuine independent assessments rather than in calibration to whoever spoke first.

When estimates diverge significantly, the team discusses why. The developer who estimated 2 points and the developer who estimated 13 points are almost certainly seeing different aspects of the work. That conversation — why the difference exists — is often where the most important information about the story emerges. Hidden complexity, unclear requirements, technical debt that one person knows about and others do not: Planning Poker surfaces these things efficiently.

The process repeats until the team reaches consensus on a single estimate.

When to question estimation

Estimation is most valuable when the team has genuine uncertainty about complexity and needs to make planning decisions. It is less valuable when work is highly routine, when the team has abundant capacity, or when the overhead of estimating exceeds the planning benefit.

Some teams move toward flow-based approaches — using cycle time and throughput data rather than upfront estimates to forecast delivery. This is a legitimate alternative, particularly for mature teams with stable processes. The Kanban Method provides the frameworks for this approach.

The key question is always: what decisions is this estimation informing, and is the information worth the effort? If the answer to the second part is yes, estimate well. If it is no, find a lighter approach.