Planning Poker: How Agile Teams Estimate with Story Points

Planning Poker is a collaborative technique agile teams use to estimate product backlog items.

It works because it combines independent thinking with team discussion. Each estimator chooses a card privately. Everyone reveals at the same time. If the estimates differ, the team talks about the differences and estimates again.

The value is not just the final number. The value is also the conversation that happens when people see the work differently.

What Planning Poker Is

Planning Poker is most useful for product backlog items that are close enough to matter but still uncertain enough to benefit from discussion. It is usually overkill for every distant idea in a large backlog, and it is usually too late if the team waits until Sprint Planning to estimate items the Product Owner needed for ordering decisions earlier.

Planning Poker is a consensus-based estimating technique. It is most often used with story points, but it can also be used with ideal days or another estimating unit.

A typical Planning Poker deck contains values such as:

0, 1, 2, 3, 5, 8, 13, 20, 40, 100

The Product Owner introduces a product backlog item. The team asks questions. Each estimator privately chooses a card. When all estimators are ready, the cards are revealed together.

If the estimates are close, the team can usually record an estimate and move on. If the estimates are far apart, the team discusses why.

That discussion is where Planning Poker earns its keep.

Why Planning Poker Works

Planning Poker helps teams avoid anchoring.

If the first person to speak says, "This is probably a three," everyone else has now heard three. Some people will adjust toward it even if they had been thinking five or eight. Others may stop thinking as carefully because an answer is already on the table.

Private selection avoids that problem. Each estimator thinks independently before seeing anyone else's answer.

The simultaneous reveal also gives quieter team members a stronger voice. A tester can reveal a high estimate because of regression risk. A developer can reveal a lower estimate because there is a simpler implementation path. A database specialist can reveal hidden migration work. The cards make those differences visible.

A team that estimates aloud too quickly can miss those signals.

Who Participates in Planning Poker

The people doing the work should estimate.

For a Scrum team, that usually means the Developers. It may also include testers, analysts, designers, database specialists, technical writers, security specialists, or anyone else whose work is needed to get the product backlog item done.

The Product Owner should participate, but not by estimating for the team. The Product Owner explains the goal, answers questions, clarifies acceptance expectations, and discusses tradeoffs. If an estimate is higher than expected, the Product Owner may decide that part of the item is not necessary or that it should be split.

The Scrum Master or agile coach often facilitates. That can mean keeping the conversation moving, reminding the team to estimate total effort, and helping the team avoid bad habits such as averaging too quickly.

Stakeholders may attend when their knowledge is useful, but they should not pressure the estimate. Planning Poker works best when estimators can be honest about uncertainty.

How to Run a Planning Poker Session

A simple Planning Poker session follows a repeatable flow.

The Product Owner introduces one product backlog item.
The team asks questions.
The team clarifies assumptions and what must be true for the item to be considered complete.
Each estimator privately chooses a card.
Everyone reveals at the same time.
If estimates differ, the team discusses, specifically, the high and low estimators explain their thinking.
The team discusses any new information.
Estimators choose again.
The team records an estimate when the discussion has produced enough shared understanding.

The team does not need perfect agreement. It needs enough agreement to support the decision the estimate will be used for.

If the item cannot be estimated because too much is unknown, record the question that needs answering. The right next step may be refinement, a spike, story splitting, or a conversation with a stakeholder.

Discuss the High and Low Estimates

When estimates differ, start with the high and low estimates.

The high estimate often reveals hidden work, risk, uncertainty, or complexity. Someone may be thinking about testing across several browsers, migrating existing data, deployment steps, security review, or support for an edge case.

The low estimate can be just as useful. It may reveal a simpler design, an existing component, a shortcut the team can safely take, or an assumption that narrows the scope.

Do not treat disagreement as a problem to remove. Treat it as information.

A team that discusses only the average estimate loses the best part of Planning Poker. The difference between a three and a thirteen is not a math problem. It is a signal that the team is seeing different work.

Do Not Average Too Quickly

Averaging estimates is tempting because it seems efficient.

If one person estimates five and another estimates thirteen, calling the item an eight feels reasonable. But the average hides the disagreement. The team may record a number without discovering why one person saw much more effort than another.

If a team is stuck after a few rounds, it can ask whether everyone can support a particular estimate. That is different from averaging. Supporting an estimate means the team has heard the concerns, understands the assumptions, and can live with the number for the decision being made.

Planning Poker should not become a debate club. But moving too quickly to arithmetic gives up the learning the technique is designed to produce.

When Planning Poker Is a Good Fit

Planning Poker works well when the team needs conversation.

Use it when:

The team is estimating items near the top of the product backlog
The Product Owner needs estimates for prioritization or tradeoff decisions
The team is learning a new domain or technology
Estimates vary because people see different risks
The team wants everyone to think independently before converging

Planning Poker may be slower than other approaches when the team has many items to estimate and only needs rough numbers. In that case, affinity estimation may be a better first pass.

Many teams use both. They use a faster technique to group many items and then use Planning Poker for items that are large, controversial, or near-term.

A Short Planning Poker Example

Suppose a team is estimating this product backlog item:

As a customer, I can save a credit card so I can check out faster next time.

After a short discussion, the estimators reveal 3, 5, 5, 8, and 13.

The team should not average those numbers. The high estimator may be thinking about tokenization, security review, compliance, and failed-card handling. The low estimator may know the payment provider already supports most of the work. Both perspectives matter.

The Product Owner may then clarify that the first version only needs to store a provider token for logged-in users and does not need card management features yet. After that clarification, the team may converge around five.

The value of Planning Poker was not the card value. It was the discovery of different assumptions before the team committed to the work.

Use Non-Number Cards Deliberately

Many Planning Poker decks include cards that are not estimates.

A question mark can mean, "I do not understand this well enough to estimate." That is useful when someone is genuinely lost or when the item needs more refinement before the team assigns a number.

An infinity card or very large value can mean, "This is too big to estimate usefully right now." That may be a signal to split the item, create a spike, or defer estimation until the Product Owner has clarified scope.

A coffee card can mean the team needs a break. That may sound trivial, but tired estimators make poor estimates.

Do not overuse non-number cards to avoid decisions. Use them when they tell the team something important about readiness, uncertainty, or meeting quality.

When to Stop Estimating and Refine

Planning Poker can reveal that a product backlog item is not ready to estimate.

Stop and refine when:

The team cannot explain what must be true for the item to be considered complete.
Estimates remain far apart after the team discusses the high and low estimates.
The Product Owner needs to make a scope decision before the team can estimate responsibly.
The item includes several independent outcomes that should be split.
The team is guessing about a major technical or product risk.

A number can make an unclear item look more ready than it is. It is better to leave the item unestimated and capture the next question than to record a number the team does not trust.

Remote Planning Poker Tips

Remote Planning Poker works well when the team protects the same principles used in person: private selection, simultaneous reveal, and useful discussion.

A few practices help:

Use a tool that hides estimates until everyone has chosen.
Keep product backlog items visible during discussion.
Ask the high and low estimators to explain first.
Timebox discussion so one item does not consume the whole session.
Capture assumptions and decisions immediately.
Save items needing more information rather than forcing a weak estimate.

Remote estimation fails when people multitask or when one person talks the team into a number before others have thought independently. The facilitator should make space for quiet disagreement.

Common Planning Poker Problems

The Product Owner Estimates for the Team

The Product Owner owns product decisions, not the team's estimate. If the Product Owner pressures estimates downward, the team will either comply with bad numbers or stop trusting the process.

One Person Dominates the Discussion

Planning Poker starts with private estimates, but the discussion can still be dominated by a strong personality. A facilitator can help by asking the high and low estimators to speak first, especially if they are usually quiet. For more detail, see Don't Average During Planning Poker.

The Team Converts Points to Hours

If each card secretly means a number of hours or days, the team loses the benefit of relative estimation. Keep the discussion on comparison with other product backlog items.

The Team Keeps Estimating Unclear Items

A product backlog item does not become ready just because it has a number. If the team cannot describe what must be true for the item to be considered complete, slow down and refine the item before estimating.

The Meeting Takes Too Long

Planning Poker should create useful estimates, not consume all available time. Timebox discussions, defer items that need more information, and use faster approaches for items that only need rough estimates. For more detail, see 3 Roles That Need to be Involved in Agile Estimating with Planning Poker.

FAQ

Does Planning Poker require consensus?

It requires enough agreement to use the estimate. The team should discuss meaningful differences, but it does not need every person to believe the selected estimate is perfect.

Should the Scrum Master estimate?

Only if the Scrum Master is also contributing to the work being estimated. Otherwise, the Scrum Master should facilitate rather than estimate.

Can Planning Poker be used remotely?

Yes. Remote teams can use an online Planning Poker tool. The key is still the same: private selection, simultaneous reveal, and discussion of meaningful differences.