Planning Poker: How It Works and When to Skip It

Planning poker is a consensus estimation game. Someone reads one backlog item, the team asks questions, each estimator picks a card in private, and everyone turns their card over at the same moment. If the cards agree, you write the number down and move on. If they do not, the people with the highest and lowest cards explain their thinking, and the team votes again. It exists to solve two problems at once: estimates that take far too long, and estimates made by the two loudest people while everyone else waits. Scrum poker and sprint poker are the same game under other names.

Where planning poker came from

James Grenning described the game in an April 2002 paper, Planning Poker, or How to avoid analysis paralysis while release planning↗ (opens in a new tab), written for Extreme Programming release planning. His opening scene will be familiar: two people argue about one story for twenty minutes, the rest of the room drifts off, and the estimate barely moves. His fix was to make everyone commit to a number before anyone talks about numbers.

The Agile Alliance glossary↗ (opens in a new tab) traces the idea back further, to Barry Boehm’s Wideband Delphi in the 1970s, and credits Mike Cohn’s 2005 book Agile Estimating and Planning with popularizing the game in the Scrum community.

The rules: how a round runs

1. The person who knows the item best, usually the product owner or whoever asked for the work, reads it out.
2. The team asks questions until the item is clear enough to size. Keep this short; the goal is shared understanding, not a design session.
3. Each estimator picks a card without showing it. Only the people who will do the work estimate. Mountain Goat Software’s guide↗ (opens in a new tab) says the product owner should take part, but not by estimating for the team.
4. Everyone reveals at once.
5. If the cards match or sit next to each other, record the estimate and move to the next item.
6. If they spread, the highest and lowest explain. These two usually know something the others do not: a hidden dependency, or an existing piece of code that makes the job easy.
7. Vote again. Repeat until the estimates are close enough to agree on.
8. If the team still cannot agree, do not keep arguing. Grenning’s advice was to defer the story, split it, or take the low estimate.

Planning poker cards

Grenning’s original deck was not Fibonacci. It held 1, 2, 3, 5, 7 and 10, meant as unitless numbers or ideal programming days, plus an infinity card. Anything over two weeks got the infinity card, which meant the customer had to split the story. The gaps were deliberate: as estimates grow, precision falls, so the deck stops offering numbers nobody can honestly tell apart.

The deck most teams use today is a modified Fibonacci sequence. Mike Cohn explains in why the Fibonacci sequence works well for estimating↗ (opens in a new tab) that each value is roughly 60% larger than the one before, which roughly matches Weber’s law about how people notice relative differences. He replaced 21 with 20 because the exact number suggested precision the team did not have, and later added 40 and 100 for very large items.

Modified Fibonacci   0  1  2  3  5  8  13  20  40  100
Grenning, 2002       1  2  3  5  7  10  infinity (split it)
T-shirt sizes        XS  S  M  L  XL (split it)

Extras many teams add:  ?  = "I cannot size this yet"

A worked round

The item: “Validate the ZIP code on the checkout address form.” Five developers vote and reveal 2, 3, 3, 13 and 3.

• The 13 explains: the shipping-rate service rejects ZIP+4 codes, so the form change needs a matching API change and a migration for saved addresses.
• The 2 explains: there is already a validator in the shared forms package; the form only needs to call it.
• Second vote: 5, 5, 8, 5, 5. The team records 5, and files the saved-address migration as its own item, because it turned out to be separate work.

The number is the least useful output of that round. The useful output is that four people learned about the ZIP+4 problem before anyone started coding, and the backlog gained an item it was missing.

Pitfalls

Anchoring

Once someone says “this feels like a 3” out loud, the private vote is no longer private. The same happens when a manager or the product owner hints at the answer they want. The simultaneous reveal only works if nobody speaks a number first, and if the people in the room are not being pressured to estimate low.

False precision

Teams that argue for ten minutes about whether an item is a 5 or an 8 have forgotten that both are guesses. Averaging the cards is a quieter version of the same mistake: a spread of 2 to 13 is information about uncertainty, and the Agile Alliance glossary warns that forcing consensus throws it away. When the spread stays wide after two votes, the item probably needs splitting, not a better number.

Time

Grenning reported that most stories took a minute or so with the game, against 10 to 30 minutes before it. If your sessions run longer than that per item, timebox the discussion and size items during regular backlog refinement rather than saving everything for sprint planning. A team that spends an hour a week debating points should ask whether the points are buying anything.

Points as a target

Estimates turn into velocity, and velocity tends to become a target. When that happens, estimates inflate and the game stops measuring anything. Sprint velocity covers what velocity is good for and how it gets misused.

When to skip it, and size lighter

Planning poker earns its time when items are large, unfamiliar, and worked on by several people who see them differently. It is overkill when items are already small and similar, when one person does nearly all the work, or when the team agrees on almost every first vote. In those cases a coarser scale does the same job faster.

• Whether you need story points at all is its own question: do you need story points.
• Ranges, reference classes and splitting are covered in software estimation.
• Where sizing fits in the sprint itself: sprint planning meeting.
• Why chasing the total is a trap: sprint velocity.

The lightest version keeps the one part of planning poker that matters most, the private vote and the simultaneous reveal, and swaps numbers for T-shirt sizes. Give each letter a fixed meaning so nobody argues about what M means. If the team shows M, M, L, M, take M; if someone shows XL, listen to why, and split the item.

Sizing on a fenbs board

fenbs is a simple task board shared by people and AI assistants, and it has no story points, no velocity and no sprints. Each task has an optional size from XS to XL, with fixed meanings: XS is under an hour, S an afternoon, M a day or two, L about a week, and XL means too big, split it. An XL task shows highlighted on its card for that reason, and the board can be filtered by size, including tasks that are not sized yet.

Play a quick round of T-shirt poker on a call, then record the letter on the task. A connected AI assistant can set the same field with size on fenbs_create_item or fenbs_update_item. Priority stays separate, from 1 (most urgent) to 10, so how big a task is and how urgent it is never share one number. If your team agrees that nothing sized XL moves to Next Up, record that on the Decisions and rules page; every connected AI assistant reads the rules before it touches the board.