What is planning poker? A practical guide for Scrum teams

Last updated: 24 October 2026.

Planning poker is a way for a team to estimate work together. Everyone picks an estimate in private, the team reveals all the estimates at the same moment, and the people who are furthest apart explain their thinking. Then the team votes again until they roughly agree. You'll also hear it called scrum poker or pointing poker. They're the same game.

It's the most common way Scrum and agile teams do story point estimation during backlog refinement or sprint planning. James Grenning described the technique in 2002, and Mike Cohn made it popular in his 2005 book Agile Estimating and Planning.

How a round of planning poker works

Each person on the team who does the work gets a deck of cards with numbers on them. A round goes like this:

1. Read the ticket. The product owner (or whoever wrote the ticket) explains the user story or bug and its acceptance criteria.
2. Ask questions. The team clarifies anything unclear. Keep this short: the aim is to understand the work, not to design it.
3. Pick a card in private. Everyone chooses the card that matches how big they think the work is, and keeps it hidden.
4. Reveal together. On a count of three, everyone shows their card at the same time.
5. Discuss the outliers. If the numbers are spread out, the people with the highest and lowest cards explain why. Often one of them knows something the rest of the team doesn't.
6. Vote again. Repeat until the estimates converge, then record the agreed number on the ticket. Most tickets settle within two rounds.

The value isn't really the number. It's the conversation that happens when one person says 3 and another says 13. That gap usually means one of them has spotted a risk, a dependency or a shortcut the other hasn't.

What are story points?

Story points are a relative measure of size. Instead of asking "how many hours will this take?", the team asks "how big is this compared with other things we've done?" A 2-point ticket should feel about twice as big as a 1-point ticket. A 5 should feel noticeably bigger than a 3.

Points blend effort, complexity and uncertainty into one number. A ticket that's quick to code but risky to deploy can deserve more points than a long, boring one. Because points are relative, they work across people who code at different speeds. Over a few sprints, the team learns how many points it usually finishes (its velocity), which makes planning more reliable than guessing in hours.

Start by picking a small, well-understood ticket the whole team knows and calling it a 2. Size everything else against it.

Fibonacci vs T-shirt sizes

The most common planning poker deck uses a Fibonacci-like sequence: 1, 2, 3, 5, 8, 13, 21. Each number is roughly the sum of the two before it, so the gaps grow as the numbers grow. That's deliberate. The bigger a piece of work is, the less precisely anyone can size it, so the deck stops you arguing over 11 vs 12.

The other popular option is T-shirt sizes: XS, S, M, L, XL. They're easier for newer teams and for rough roadmap sizing, because nobody is tempted to treat them as hours.

Most decks also include a ? card ("I can't estimate this yet") and sometimes a coffee card ("I need a break"). A lot of question marks is a useful signal: the ticket probably needs more refinement before anyone should commit to it. Anything that lands on 13 or 21 is usually worth splitting.

Why private voting reduces anchoring

The most important rule in planning poker is that nobody sees anyone else's estimate until everyone has chosen. The reason is a well-studied bias called anchoring: once people hear a number, their own estimate drifts towards it, even when the number is unrelated to the question.

In a normal meeting, the first person to say "that's about a 3" sets the anchor. That's often the most senior or most confident person, not the one who knows the work best. Quieter team members then nudge their estimates towards 3 rather than say 8 and explain why. The team loses exactly the information it needed.

Simultaneous reveal fixes this. Everyone commits before they can be influenced, so the spread of numbers is honest. A wide spread isn't a failure: it's the point. It tells the team where to talk.

A few habits keep it working:

• Don't think out loud before voting. "Hmm, that's tiny" is an anchor too.
• Let the outliers speak first, and don't make them justify themselves to the majority.
• Don't average the votes. A 3 and a 13 averaging to 8 hides the disagreement instead of resolving it.
• Keep the facilitator neutral. If the Scrum Master or product owner votes, they vote in private like everyone else.

How to run planning poker remotely

Physical cards don't work on a video call: people can see each other hesitate, and someone always reveals early. For remote and hybrid teams, use an online planning poker tool where each person votes from their own browser and the tool controls the reveal.

A good remote setup looks like this:

1. Prepare the tickets first. Load them from Jira or paste them in before the meeting, so nobody watches you scroll the backlog.
2. Share one link or code. The fewer steps to join, the better. Requiring accounts for every player is the most common reason remote sessions start late.
3. Screen-share the ticket, not the votes. Everyone reads the same description; votes stay private in each person's browser.
4. Let the host reveal. A single "reveal" button keeps the moment simultaneous, even with network lag.
5. Timebox each ticket. Two or three minutes of discussion is usually enough. If the team still disagrees after two rounds, park the ticket for more refinement.
6. Write the result straight back. Copying numbers into Jira by hand after the meeting is where estimates get lost.

That's what Pointwalk is built for. Each player walks a character to their estimate in secret, so nobody sees a number before the reveal. When the host hits reveal, everyone's walk replays at once, which makes the spread obvious and the outliers easy to spot. Players join with a six-letter code and need no account. Hosts can load issues from Jira Cloud and write story points back automatically. If you'd rather compare options first, see our guide to the best free planning poker tools. For in-person sessions, print a free deck of cards.

Common planning poker mistakes

• Estimating in hours with extra steps. If everyone silently converts points to hours, you lose the benefit of relative sizing.
• Comparing velocity between teams. One team's 5 isn't another team's 5. Points only mean something within a team.
• Re-voting until the majority wins. Convergence should come from new information, not pressure.
• Estimating tickets nobody understands. If the room is full of question marks, stop and refine the ticket.
• Letting sessions run long. Estimation fatigue is real. Keep sessions under an hour, or take a break (that's what the coffee card is for).

Questions