What is planning poker? A quick guide for agile teams

9 October 2026 · 6 min read

New to an agile team? Then you may have seen everyone pick a number in secret and show it at the same moment. It looks like a card game, and in a way it is one. Here is what's going on, and how to run your own session in a couple of minutes.

What is planning poker?

Planning poker, also called scrum poker, is a way for a team to estimate work together. It doesn't rely on one senior developer's guess. Everyone estimates the same task at the same time, and the team then talks through any disagreement.

The "poker" is the cards. Each person chooses a card with their estimate and keeps it face down. All the cards are then turned over together, so nobody is swayed by a number someone said first.

Why not let the lead estimate everything?

Because the first number spoken out loud becomes an anchor. Once someone says "that's two days", everyone else quietly adjusts towards two days, even those who were thinking of a week. Psychologists call this anchoring, and it affects experienced engineers as much as anyone.

Planning poker gets around it with one rule: vote in secret, reveal together.

• Independent judgement. Each estimate is someone's own view, not an echo of the loudest person in the room.
• Useful disagreement. When a 3 and a 13 land side by side, that gap is the conversation worth having.

The gap is where the value lies. A wide spread usually means one person knows about a hidden complication, or another has misread the story. Either way, you find out before the work starts rather than halfway through the sprint.

How a round works

A round takes a few minutes:

1. Present the story. The product owner or facilitator reads out a user story or task and answers questions about it.
2. Everyone votes in secret. Each person picks the card that matches their estimate.
3. Reveal together. All the cards are turned over at the same moment.
4. Discuss the outliers. The people with the highest and lowest cards explain their thinking.
5. Vote again. With the new information on the table, the team estimates once more.

Repeat until the votes are close enough to agree on a number. Most stories settle within one or two rounds.

What do the numbers mean?

The cards are rarely a plain 1 to 10. The most common deck follows the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21 and so on. The widening gaps reflect something every developer has learned: the bigger a task, the less precisely you can estimate it. A 1 and a 2 are clearly different, but "is this a 20 or a 21?" is not a question worth arguing about.

Teams use a few popular decks. All of them are built into Storyvote:

• Fibonacci (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ?, ☕)
• Modified Fibonacci (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, ☕)
• T-shirts (XS, S, M, L, XL, ?, ☕)
• Powers of 2 (0, 1, 2, 4, 8, 16, 32, 64, ?, ☕)

Modified Fibonacci rounds the big numbers to 20, 40 and 100, because by then the precision of 21 or 34 is false comfort anyway. T-shirt sizes suit quick, rough sizing early on, before a story is broken down. Whatever the deck, the idea is the same: relative size, not exact hours.

Most decks also have two special cards. ? means "I can't estimate this yet", which is usually a sign the story needs clarifying. ☕ means "I need a break". Neither counts as an estimate.

Story points, not hours

Planning poker usually estimates in story points, a unit of relative effort that blends how much work there is, how complex it is and how much is unknown. A 5 isn't five hours or five days. It is "about two and a half times a 2".

Relative estimates hold up better than hours. People are poor at predicting how long something will take, but good at judging whether one task is bigger than another. Over a few sprints, the points a team completes per sprint (its velocity) turn those relative sizes into a reliable forecast. Read more in Story points: measuring complexity and capacity.

Where it came from

James Grenning described planning poker in 2002 as a way to stop release planning from stalling in endless discussion. Mike Cohn popularised it in his 2005 book Agile Estimating and Planning. Its roots go back further, to Wideband Delphi, an estimation method in which experts estimate independently, compare and discuss their answers, and repeat until they converge.

Tips for your first session

• Estimate effort, not time. Ask "how big is this compared with that?", not "how many hours?".
• Pick a reference story. Agree on one well-understood story as, say, a 3, and size everything else against it.
• Timebox the discussion. A couple of minutes per story, then vote again. If you still can't agree, the story probably needs splitting or more research.
• Don't average the votes. A 3 and an 8 don't make a 5.5. They are a conversation you haven't had yet.
• Let everyone who does the work vote. Developers, testers and designers all see different risks. The product owner explains the story but usually doesn't vote.
• Keep remote reveals simultaneous. On a call you can't read the room, so hidden votes matter even more. A tool that keeps votes hidden until the reveal does this for you.

Run your first round on Storyvote

Storyvote is free planning poker that runs in the browser. There is no account to create and no trial or payment. To start:

1. Create a room: give it a name, pick a deck and type your name.
2. Copy the invitation link and share it in your team chat or meeting.
3. Add a story and press its Vote button. Everyone picks a card in secret.
4. Reveal the votes. After a short countdown, everyone sees the cards, the average and how the votes spread. When everyone agrees, there's a little celebration.
5. Save the agreed estimate and move on to the next story.

Votes stay hidden on the server until the reveal, so nobody can peek. You can also split a story by discipline, such as frontend, backend and QA, or make voting fully anonymous. The FAQ covers the details.

← All articles