How to run planning poker (step by step)

Planning poker is a consensus-based estimation technique where each team member privately picks a card for the effort of a task, everyone reveals at the same time, and the team discusses any disagreement until they converge on a shared estimate. It is the most widely used expert-judgment technique in agile estimation research. To run it you need a team, a set of items to estimate, and an estimation deck, then you follow the seven steps below.

What is planning poker?

Planning poker (also called scrum poker or pointing poker) turns estimation into a short, structured game. Instead of the loudest or most senior person setting the number, everyone commits to an estimate privately and reveals it at once. That single rule, simultaneous reveal, is what makes the technique work.

Why it works: the science of estimating together

The reason planning poker reveals cards simultaneously is to avoid anchoring, the well-documented bias where the first number mentioned drags everyone else's estimate toward it. In controlled experiments, simply showing software professionals an arbitrary number before they estimated pulled their estimates strongly toward it. The effect was large, and a training workshop built to counter it only softened the pull rather than removing it. Anchoring has long been identified as an important cause of software estimates that come in too low.

Estimating as a group also helps. In a study that added planning poker to real project tasks, the estimate the team agreed on after discussing was less optimistic than simply averaging everyone's individual guesses, and ended up closer to the actual effort. (Full references in Sources below.)

What you need before you start

• A team of the people who will do the work (typically 3 to 9).
• A prioritized list of user stories or tasks to estimate.
• An estimation deck (see step 2).
• A facilitator (often the Scrum Master) and someone who can answer questions about each item (often the Product Owner).

How to run planning poker: 7 steps

1. Set up the room and invite the team. Create a session and share the link. With Planning Poker Web, anyone can join with no account: they open the link and they are in. Facilitation tip: agree on the deck and a reference story ("this small bug = 2 points") before you start, so everyone calibrates to the same scale.
2. Choose an estimation deck. Pick the scale the team will vote with (Fibonacci, T-shirt sizes, and so on). Tip: keep the same deck across sprints so your velocity stays comparable.
3. Present the first user story. The Product Owner reads the item and answers clarifying questions. Keep it short, because detail comes out in discussion. Time-box: about 2 minutes of presentation.
4. Everyone votes at the same time. Each person privately selects the card that matches their sense of the effort. No numbers are spoken yet. Tip: include everyone who does the work, testers and designers, not just developers.
5. Reveal all cards together. When everyone has voted, reveal simultaneously. This is the anti-anchoring step: nobody's vote was influenced by another's.
6. Discuss the outliers. If estimates differ, the highest and lowest voters explain their reasoning. This surfaces hidden assumptions, missing tasks, and risks, often the most valuable part of the session. Time-box: about 3 to 5 minutes. If it runs longer, the story is probably too big.
7. Re-vote until you converge. Vote again after the discussion. Repeat until the team lands on a shared number. Record it and move to the next item. Tip: "converge" means close enough to agree, not identical, so do not chase a unanimous card.

A worked example: estimating one user story

Say the story is "User can reset their password by email." The Product Owner reads it, and a tester asks whether rate-limiting is in scope (it is). The team votes on a Fibonacci deck and reveals:

The tester (8) explains: the reset flow needs rate-limiting, email-template work, and edge cases for expired tokens, none of which the others pictured. That is exactly the hidden work planning poker is designed to surface. After the discussion the team re-votes (5, 5, 8, 5) and agrees on 5. The number matters less than the fact that the whole team now shares the same picture of the work.

Running planning poker remotely vs. in person

The mechanics are identical. The facilitation differs.

• In person: physical cards work, but someone has to transcribe results and there is no automatic history. Watch for people revealing slowly and influencing others.
• Remote or distributed: a shared online room is essential. Reveal is enforced by the tool (nobody sees votes early), results and history are captured automatically, and async voting lets teams across time zones estimate without a live call. This is where a tool like Planning Poker Web replaces the physical deck entirely. See our guide to planning poker for remote teams for live and async setups.

When NOT to use planning poker

Planning poker is not always the right tool. Skip it, or choose something faster, when:

• The backlog is huge (50+ items). Item-by-item voting is too slow. Use affinity estimation or the bucket system for a first pass, then planning poker only on the uncertain items.
• One person clearly owns the work. With no diversity of perspective, the group ritual adds little over a quick expert estimate.
• The team already shares a clear mental model. For well-understood, repetitive work, estimates rarely diverge, so the discussion has little to surface.
• You are estimating for a long-range roadmap, not a sprint. Rough sizing (T-shirts) is enough, and precise relative points are wasted effort that far out.

Being honest about this builds trust. Forcing planning poker onto the wrong situation is how teams come to resent estimation.

Difficult scenarios (and how to handle them)

• The team cannot converge after two rounds. The story is usually too big or too vague. Split it, or send it back to the Product Owner for clarification.
• One person dominates the discussion. The private vote already limits this. Reinforce it by asking the lowest voter to speak first, not the senior person.
• Someone always votes with the majority. Ask them to vote before reading the room. In a tool, votes are hidden until reveal, which removes the temptation.
• Estimates are consistently too low. This is optimism and anchoring at work. Keep a visible reference story and compare new items against it rather than estimating in a vacuum.

Planning poker vs. other estimation techniques

Common mistakes to avoid

• Speaking a number before the reveal, which re-introduces anchoring.
• Estimating in hours instead of relative points. Relative sizing is faster and less biased.
• Averaging instead of discussing. The discussion is the point, and the number is the by-product.
• Letting one person dominate. The private vote exists precisely to prevent this.
• Re-voting forever. Chasing a unanimous card wastes time, so "close enough to agree" is the goal.

Glossary: planning poker terms

• Story point: a unit of relative effort (not hours), combining complexity, uncertainty and volume of work.
• Deck: the set of cards the team votes with (e.g., Fibonacci, T-shirt sizes).
• Velocity: how many points a team completes per sprint, used to forecast, not to compare teams.
• Anchoring: the bias where the first number mentioned pulls other estimates toward it, the reason votes reveal simultaneously.
• Outlier: the highest or lowest vote, whose reasoning the team discusses first.
• Reference story: a previously estimated item the team compares new stories against, to keep the scale stable.

Frequently asked questions

How long does a planning poker session take?

For a normal sprint backlog, 30 to 60 minutes. A single item usually takes 1 to 3 minutes unless estimates diverge and need discussion.

How many people should join?

Typically the 3 to 9 people who will actually do the work. Fewer than three loses the benefit of diverse views, and more than nine slows discussion.

What deck should we use?

Fibonacci (0, 1, 2, 3, 5, 8, 13 and up) is the common default because the growing gaps reflect rising uncertainty for larger items. T-shirt sizes suit early, rough sizing.

Why do all cards reveal at the same time?

To prevent anchoring, the bias where the first number spoken pulls everyone's estimate toward it. Simultaneous reveal keeps each vote independent.

Do we estimate in hours or points?

Relative points (story points) are recommended. They are faster to agree on and less prone to the optimism bias that hour-based estimates show in research.

What if the team cannot agree?

Let the highest and lowest voters explain, then re-vote. If it still will not converge, the item is probably too big or too vague, so split it or send it back for clarification.

Can you run planning poker asynchronously?

Yes. With an online tool, team members vote on their own time and reveal once everyone has voted, which is useful for distributed teams across time zones. The anti-anchoring benefit still holds because votes stay hidden until reveal.

Who should participate, and should the Scrum Master vote?

Everyone who does the work (developers, testers, designers). The Scrum Master usually facilitates rather than votes, and the Product Owner answers questions but does not estimate.

Is planning poker the same as scrum poker?

Yes. "Scrum poker" and "pointing poker" are common synonyms for the same technique.

Sources

1. Moløkken-Østvold, Haugen & Benestad (2008). Using planning poker for combining expert estimates in software projects. Journal of Systems and Software, 81(12), 2106 to 2117.
2. Mahnič & Hovelja (2012). On using planning poker for estimating user stories. Journal of Systems and Software, 85(9), 2086 to 2095.
3. Jørgensen & Sjøberg (2001). Anchoring effects: an important cause of too optimistic effort estimates. Simula.
4. Løhre & Jørgensen (2016). Numerical anchors and their strong effects on software development effort estimates. Journal of Systems and Software.
5. Shepperd et al. (2018). An Experimental Evaluation of a De-biasing Intervention for Professional Software Developers. arXiv:1804.03919.