Estimation with Story Points

Why Estimation?

Estimation helps teams prioritize — determining which User Stories to tackle first and which to defer. A User Story with high business value might still be scheduled later if it carries a disproportionately large effort, while a medium-value story requiring little work may be delivered sooner. This cost-performance trade-off is a key driver of prioritization in Agile development.

Estimate with Story Points

Story Points are the most common unit for estimating User Stories in Agile teams. Rather than estimating in hours or days — which implies false precision and nudges teams toward treating estimates as commitments — Story Points measure the relative effort of a story, factoring in complexity, uncertainty, and scope.

For example, if “Sub-Story A: Pay via Credit Card” is estimated at 5 points, and the team agrees that “Sub-Story C: Apply a Discount Code” is roughly twice as complex, it would be estimated at 10 points. The absolute numbers don’t matter — what matters is that the team agrees on the relative size between stories.

The most widely used scale is the Fibonacci sequence (1, 2, 3, 5, 8, 13, …). The growing gaps between numbers are intentional: they reflect the natural increase in uncertainty as stories get larger. A story estimated at 13 is not just “a little bigger” than an 8 — it is significantly more uncertain and should ideally be broken down further.

Planning Poker

Planning Poker is a popular technique for reaching a Story Point estimate as a team. Here is how a typical round works:

  1. The Product Owner reads out a User Story and answers any clarifying questions.
  2. Each team member privately selects a card representing their estimate using the Fibonacci scale.
  3. Everyone reveals their cards simultaneously.
  4. If estimates differ significantly — for example, one member says 3 and another says 13 — each person briefly explains their reasoning.
  5. The team discusses, then re-estimates until a consensus is reached.

The simultaneous reveal is the key: it prevents anchoring, where an early vocal estimate influences everyone else’s judgment.

Planning Poker can be played with a physical deck, but many teams use online tools. Two popular options are Pointing Poker and PlanITpoker

Velocity

Once a team has completed a few sprints, their average Story Points completed per sprint becomes their velocity. For example, if a team consistently completes around 30 points per sprint, the Product Owner can use that figure to forecast how many sprints it will take to deliver a set of stories.

Velocity is a planning tool — not a performance metric. It is only meaningful within the context of a single team’s own estimates. Comparing velocity across teams is a common pitfall: Team A’s “5 points” and Team B’s “5 points” are not equivalent, because each team calibrates their scale independently. Using velocity to rank or compare teams encourages score-gaming and undermines honest estimation.