Story Points and Planning Poker Explained

Estimating work in software development is rarely as simple as asking, “How many hours will this take?”

Requirements change. Technical details emerge during development. Dependencies appear. Some work looks small until the team starts investigating it.

This is why many Agile teams use Story Points and Planning Poker to discuss the relative size of Product Backlog items.

However, there is an important distinction to understand: Story Points and Planning Poker are not required elements of Scrum. Scrum Teams can choose their own approach to estimation and forecasting. Scrum.org sources specifically note that these practices are commonly used but are not mandated by the Scrum framework. 

What Are Story Points?

Story Points are a way of expressing the relative size of work.

Instead of saying:

“This will take 16 hours.”

A team might say:

“This item is larger than our 3-point item but smaller than our 8-point item.”

The number itself has no universal meaning.

A 5-point item for one team does not mean the same amount of work as a 5-point item for another team. Scrum.org discussions emphasize that teams establish their own reference points and use relative sizing rather than treating points as units of time. 

Teams commonly use sequences such as:

1, 2, 3, 5, 8, 13

The increasing gaps make it harder to pretend that estimates are more precise than they really are.

What Goes Into a Story Point Estimate?

A team may consider factors such as:

• Complexity

• Amount of effort

• Technical difficulty

• Dependencies

• Uncertainty

• Unknowns

For example, imagine three Product Backlog items:

Item A: Change a button label
Estimate: 1 point

Item B: Add a new payment option
Estimate: 5 points

Item C: Build an entirely new payment integration with an external provider
Estimate: 13 points

The numbers don't represent hours. They express how the items compare with one another.

The important part is the discussion that leads to the estimate.

What Is Planning Poker?

Planning Poker is a collaborative estimation technique.

Each Developer privately selects a card representing their estimate. The cards are revealed together, rather than allowing the first person's estimate to influence everyone else's decision.

If everyone chooses the same number, the discussion can move forward.

If the estimates are different, the people with particularly high or low estimates explain their reasoning. The team then discusses the differences and estimates again.

This is where Planning Poker becomes useful.

The goal isn't to find the “perfect” number.

The goal is to uncover different assumptions and build a shared understanding of the work.

Scrum.org contributors have highlighted this discussion as one of the major benefits of Planning Poker and Story Points. Different estimates can expose gaps in understanding or areas of uncertainty. 

A Simple Planning Poker Example

Suppose a team is discussing a Product Backlog item:

“Allow customers to save a payment method for future purchases.”

Four Developers reveal:

3 | 5 | 5 | 13

The 13 immediately raises a question.

The Developer who selected 13 explains that they believe the feature requires changes to the payment gateway and additional security work.

Another Developer had assumed that an existing payment service already supported the required functionality.

Now the team has discovered an important technical question.

Instead of simply choosing 5 because most people selected it, the team investigates the uncertainty.

That conversation may result in a better-understood backlog item and a more informed estimate.

Story Points Are Not Hours

One of the most common mistakes is turning points into time.

For example:

1 point = 1 day
5 points = 5 days

This defeats much of the purpose of relative estimation.

Scrum.org discussions caution against equating points with time because it can create misleading assumptions about how long work will take. 

Story Points are better viewed as a way of comparing work.

The team might decide that a familiar, completed item is a 3-point reference. A new item that appears roughly twice as large might receive 5 or 8 points, depending on the team's scale and reasoning.

Does Scrum Require Story Points?

No.

This is an important point for anyone learning Scrum.

The Scrum framework does not require Story Points, Planning Poker, or velocity.

Scrum.org explicitly states that Scrum Teams are free to choose how they estimate their work. 

A team may use Story Points, T-shirt sizing, hours, item counts, or another approach.

The method matters less than whether it helps the team understand the work and make sensible decisions.

Should Teams Use Story Points to Measure Performance?

This is where caution is needed.

Story Points are subjective. They are created for a team's own use and should not be treated as a productivity score.

Comparing one team's 30 points with another team's 30 points doesn't tell you which team is performing better.

Scrum.org has repeatedly warned against using Story Points as a universal performance measure or comparing points between teams. 

A team should also avoid pressuring Developers to increase their point totals. That can encourage unhealthy estimation behavior rather than better product outcomes.

The Real Value Is the Conversation

Planning Poker is sometimes treated as a card game for selecting numbers.

That's missing the point.

Its real value comes from the conversation.

When two Developers choose very different estimates, the difference gives the team something worth discussing:

What does one person know that another doesn't?

Perhaps there is an unknown dependency.

Perhaps the acceptance criteria aren't clear.

Perhaps the implementation approach is different.

Perhaps the Product Backlog item is simply too large.

That conversation can lead to better refinement and clearer work.

Final Takeaway

Story Points and Planning Poker are optional Agile practices, not mandatory Scrum requirements.

When used thoughtfully, they can help Developers discuss complexity, uncertainty, effort, and assumptions before taking work into a Sprint.

The number itself is not the goal.

Shared understanding is.

A useful estimation session should leave the team with a clearer understanding of the work, not simply a number attached to a Product Backlog item.

For teams that choose to use Story Points and Planning Poker, the best approach is to keep the focus where it belongs: understanding the work, exposing uncertainty, and making better decisions together.