Planning poker: the complete guide

Planning poker is a consensus-based estimation technique used by agile teams. Every person on the team picks a card that represents their estimate for a piece of work, everyone reveals their card at the same time, and the team talks through the differences until it agrees on a number. Many teams call it scrum poker, because it is most often used during Scrum backlog refinement and sprint planning, but it works with any iterative process.

The game is popular because it is cheap, quick and surprisingly good at surfacing hidden assumptions. The number at the end matters, but the conversation that produces it matters more.

Where planning poker comes from

Planning poker was first described by James Grenning in 2002. He was looking for a way to make estimation meetings shorter and to stop a few loud voices from dominating them. The technique reached a wider audience through Mike Cohn's book Agile Estimating and Planning, which presented it as a practical way to estimate user stories in relative units such as story points.

The core idea borrows from the Wideband Delphi method: collect independent opinions first, then discuss, then estimate again. Planning poker turns that idea into something a team can do in a couple of minutes per item.

How a planning poker round works, step by step

Here is how to play planning poker with a typical team of four to eight people.

1. Present the story. The product owner reads the user story and its acceptance criteria. For example: "Add password reset by email".
2. Clarify. The team asks questions. Does the reset link expire? Do we already send transactional email? Keep this short; the goal is shared understanding, not a design session.
3. Vote privately. Each estimator picks a card without showing it. Cards usually follow a Fibonacci-like scale such as 1, 2, 3, 5, 8, 13.
4. Reveal together. All cards are turned over at once. Simultaneous reveal is the most important rule, because it stops people from anchoring on the first number they hear.
5. Discuss the spread. If estimates differ, the people with the lowest and highest cards explain their reasoning. Often one of them knows something the others do not.
6. Vote again or agree. After the discussion the team votes again. Usually the second round converges. If it does, record the estimate and move to the next story.

Suppose the team's reference story is "Let users change their display name", which everyone agreed was a 2. For password reset, two developers vote 3, one votes 5 and one votes 13. The developer who voted 13 points out that the app has no email service yet. That changes the picture: the team either splits out "Set up transactional email" as its own story or agrees the reset story is an 8. Without the simultaneous reveal, that risk might never have been mentioned.

Planning poker rules

The rules are short, and most of them exist to protect independent thinking.

• Everyone who does the work votes. Developers, testers and designers estimate. The product owner explains the story and answers questions but usually does not vote.
• Votes stay secret until the reveal. Nobody says a number out loud before the cards are turned.
• Estimates are relative. A 5 means "a bit more than twice the size of our 2", not five hours or five days.
• Outliers speak first. The lowest and highest voters explain, without being put on trial.
• The team owns the number. A manager or senior developer does not overrule the team.
• Special cards have meaning. A "?" means "I can't estimate this yet" and a coffee card means "I need a break". Both are valid votes.

Who takes part

A planning poker session normally includes the development team, the product owner and a facilitator (often the Scrum Master). The facilitator keeps time, makes sure every voice is heard and records the agreed estimates. Stakeholders can watch, but they should not vote; in an online tool that is what a spectator role is for.

When to use planning poker

Planning poker is a good fit when stories are small enough to discuss in detail and the team needs estimates precise enough for sprint planning. It is less useful for a backlog of 200 rough ideas; for that, faster methods like t-shirt sizing or affinity estimation work better. Our guide to agile estimation techniques compares the options.

Common mistakes

• Turning points into hours. Once a 1 means "one day", the team starts estimating time again and loses the benefit of relative sizing.
• Averaging without talking. If the votes are 2 and 13, the average is meaningless. The gap is the signal.
• Endless debate. Some stories will never reach perfect agreement. After two or three rounds, take the higher estimate or split the story.
• Estimating unclear stories. If nobody can explain the acceptance criteria, the story is not ready. Send it back to refinement.
• Comparing velocity between teams. Each team's scale is its own. A 5 in one team is not a 5 in another.

Tips for facilitators

Prepare the agenda

List the stories you want to estimate before the meeting, in priority order, and make sure each has a clear title and acceptance criteria. In Scrum Poker you can paste the stories one per line and the session steps through them.

Keep a reference story visible

Pick one or two well-understood stories the team has already finished and keep them in view. Relative estimates need something to be relative to.

Timebox discussion

Two to three minutes of discussion per story is usually enough. A visible timer helps; when it runs out, vote again.

Watch the agreement, not just the number

When results show a wide spread, that is where to spend time. When everyone voted the same card, accept it and move on quickly. If you work with a distributed team, see our guide to remote planning poker for extra tips.

Running planning poker online

Physical cards work fine in a room, but most teams now estimate at least partly online. Scrum Poker is a free tool built for this: the facilitator opens a session in one click and shares an invite link or QR code, participants pick cards on their laptop or phone, votes stay hidden until everyone's cards are revealed at once, and the results show the average, median, level of agreement and who voted lowest and highest. The facilitator keeps the agreed estimate and moves on, and at the end the session summary lists total points and can be copied as text or downloaded as CSV. You can start a free session and try it with your team today.