Planning poker is a way for a team to estimate work together. Each person picks a card with a number on it, everyone shows their card at the same moment, and the people with the highest and the lowest numbers explain why. Then the team votes again, until the numbers agree.
It works because nobody can follow anyone else's number, and because the disagreements come out before the work starts, not halfway through it. This guide covers how to play, step by step, what the numbers mean, a worked example, and the mistakes that make the estimates useless. It also has a deck to print: the planning poker cards Redbooth made for its own sprint planning, free to use.
Download the deck (PDF, 4 pages). Print it on card, double-sided, and cut along the marks: you get one full deck, so print one copy per player. The cards are also on GitHub as separate images, under a Creative Commons Attribution license.
How to Play Planning Poker
The people who'll do the work hold the cards. The Product Owner brings the items and answers questions, and the Scrum Master, if the team has one, keeps the game moving. (Who does what on a Scrum team is in our guide to agile team roles.) For each item:
- Read the item. The Product Owner reads one backlog item aloud and says why it matters.
- Ask questions. The team asks what it needs to know; the Product Owner answers. Keep it to a couple of minutes.
- Pick a card in private. Each estimator chooses the card that matches the size of the item, and keeps it face down.
- Reveal together. Everyone turns their card at the same moment, so nobody adjusts their number to someone else's.
- Talk about the extremes. If the numbers are close, take the most common one and move on. If not, the people with the highest and lowest cards explain what they know that the others might not.
- Vote again. Most items agree by the second or third round. If they don't, take the higher number, or split the item and estimate the parts.
- Write it down. Record the estimate on the item and move to the next one.
Give each item a few minutes at most. An item that takes longer usually needs more refinement, not more voting: put it aside, find out what's missing, and estimate it next time.
What the Numbers on the Cards Mean
Most decks follow the same sequence: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 and 100, plus a ? card, and often an ∞ card and a coffee cup. The numbers start like the Fibonacci sequence, where each number is the sum of the two before it, and then round off.
The numbers are story points: the size of an item compared with the others, which takes in the effort, the complexity and the uncertainty. They aren't hours. The gaps get wider as the numbers grow because a big item can't be estimated precisely; nobody should spend a meeting deciding whether something is a 14 or a 15. To start, agree on a small item everyone knows well and call it a 2 or a 3. Every other item is then "about as big as that", "twice as big", or "much bigger".
| Card | What it usually means |
|---|---|
| 0, ½, 1 | Almost nothing to do: a text change, a small setting |
| 2, 3, 5 | Small to medium items the team understands well |
| 8, 13 | Big items, with some unknowns; worth checking whether they can be split |
| 20, 40, 100 | Too big for one sprint: split them before the team commits to them |
| ? | "I don't know enough to estimate this" |
| ∞ | "This can't be done as written" |
| Coffee | "I need a break" |
Example: One Round, Step by Step
Kestrel Travel, a fictional company, has a check-in team of five Developers: Lena, Marco, Joy, Sam and Kofi. At the sprint's planning meeting, Ana, the Product Owner, reads the next item: travelers can change their seat after they've checked in.
In the first round, three people show 5, Marco shows 3 and Joy shows 13. Marco explains that the seat map from the check-in screen can be reused as it is. Joy explains what nobody else knew: the airline's system needs a separate request to release the old seat before it books the new one, and it only takes one at a time. The team votes again, and this time everyone shows 8.
Both explanations were right, and the second vote takes both into account. Without the cards, Joy might never have mentioned the airline's limit, and the team would have found it in the middle of the sprint.
Redbooth's Deck, Card by Card
In 2015, Redbooth made a deck for its own sprint planning, with an idiom for each number, some of them in Spanglish and some inside jokes from the office. It has every card a team needs from 1 to 100, plus a few of its own:
| Card | The idiom | The drawing |
|---|---|---|
| 1 | Low-hanging fruit | An orange on a branch |
| 2 | Piece of cake | A slice of strawberry cake |
| 3 | It ain't rocket science | A rocket and an astronaut |
| 5 | Ornitorrinco, Spanish for platypus, because it rhymes with cinco | A platypus |
| 8 | An arm and a leg | An arm and a leg |
| 13 | Just squeaking by | A cat's paw over a mouse's tail |
| 20 | Don't put all your eggs in one basket | A basket of eggs |
| 40 | Meterse en un berenjenal, Spanish for getting yourself into an eggplant field: a mess | A field of eggplants |
| 100 | Monster task | A dinosaur scaring a unicorn |
| ∞ | When pigs fly | Flying pigs |
| ? | Here be dragons | A dragon |
| Break | Time for a game of ping-pong | A ping-pong paddle |
| Brownie | From the Spanish marrón: a job nobody wants | A brownie on a checked tablecloth |
| Yak | Yak shaving: the chain of side tasks you have to finish before the real one | A yak about to be shaved |
The deck has no 0 or ½. If your team uses them, draw your own; the license lets you change the cards, as long as you credit Redbooth. The brownie and the yak aren't estimates: play them when the item is unpleasant, or when you suspect it hides more work than it shows.
Download the deck (PDF), or get the PNG and SVG files from GitHub.
Story Points, Hours and Velocity
Once a team has estimated a few sprints' worth of items, it knows roughly how many points it finishes per sprint: its velocity. At the next sprint planning, the team uses it as a guide to how much work to take on.
That's all points are for. Converting them into hours brings back the false precision they were meant to avoid, and comparing velocity between teams is meaningless, because each team's "3" is its own. If a team prefers to estimate in hours, it can; it just doesn't need cards with gaps in them.
Variations
- T-shirt sizes. XS, S, M, L and XL instead of numbers, for early, rough estimates of big pieces of work.
- Online planning poker. For remote teams, an app or a shared screen does the reveal. Without one, everyone types their number into the chat at the same moment.
- Affinity estimation. For a long backlog: the team lays all the items out in a line from smallest to largest, then marks where each number starts. It's quicker than a round per item.
Mistakes That Make the Estimates Useless
- Showing cards one at a time. The first number becomes the anchor, and the vote measures who spoke first.
- Averaging the numbers. A 3 and a 13 average to 8, and hide the conversation that would have told you which is right.
- Letting the most senior person speak first. Everyone else adjusts to them before the reveal.
- Estimating what nobody understands. That's what the ? card is for: refine the item, then estimate it.
- Using points to judge people. Once velocity becomes a target, the estimates grow until the target is met.
Record the Estimates in Redbooth
Planning poker ends with a number on each item, and the number is only useful where the team plans its sprints. In Redbooth, each backlog item is a task, so the estimate goes on the task:
- Keep new items in a "To estimate" list, so the next session knows where to start. An item that got a ? stays there, tagged, until it has been refined.
- Add the points as a tag when the team agrees them: 3 pts, 5 pts, 8 pts. Tags show on every card on the board, so the size of each item is visible at sprint planning, and you can filter the board by them. Creating and editing tags is on the Pro plan and above.
- Move estimated items into the product backlog, and at sprint planning, move the ones the team commits to into the sprint's task list, adding up their points against the team's velocity.
- Note what the extremes said. If a round surfaced something like the airline's one-request limit, put it in the task's comments, where the person who picks the task up will see it.
Teams that estimate in hours instead can use task time estimates, on the Business plan and above.
Questions People Ask
What numbers are on planning poker cards?
Usually 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 and 100, with a ? card, and often ∞ and a coffee cup. Redbooth's deck has 1 to 100, ∞, ?, a break card and two joke cards.
Why does planning poker use the Fibonacci sequence?
Because the gaps between the numbers grow with them, as the uncertainty of an estimate does. A team can tell a 2 from a 3, but not a 21 from a 22, so the deck doesn't offer the choice.
How many cards does each player need?
A full deck each, so everyone can pick any number in private. Redbooth's PDF prints one deck; print one copy per player.
Who should vote in planning poker?
The people who'll do the work. In Scrum, that's the Developers. The Product Owner explains the items and answers questions, but doesn't vote.
Can I use Redbooth's planning poker cards for free?
Yes. They're under a Creative Commons Attribution 3.0 license: you can print them, share them and change them, at work too, as long as you credit Redbooth.
Print a deck for your next sprint planning, agree on what a 3 means with an item everyone knows, and play the first round on the item the team is least sure about.