Planning poker: how to estimate as a team

A team sizes work together: everyone picks a card in secret, the cards are shown at once, and the gaps start the talk. How to run it and play it in Prior.

6 min read

Planning poker is a way for a team to estimate the size of work together. Everyone picks a card in secret, all the cards are shown at the same moment, and the team talks about the differences before settling on a number. The number matters less than what the talk brings out.

A storyRead it togetherVoteEveryone picks acard, hiddenRevealAll cards at onceTalkHigh and lowexplainSaveOr vote againFar apart? Vote again
A round of Planning Poker

Where it comes from

James Grenning defined and named planning poker in 2002. Mike Cohn made it widely known in his book Agile Estimating and Planning (2005). It is a variation of Wideband Delphi, a group estimation method that grows out of the Delphi method developed at the RAND Corporation: estimate on your own first, compare, discuss, estimate again.

Teams use it with story points, a relative measure of size. Cohn's deck follows a Fibonacci-like sequence: 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. The gaps widen on purpose: the bigger a piece of work, the less precisely anyone can size it, so the deck does not offer a 14 or a 15.

Why it works

Secret cards stop anchoring. When the first person names a number aloud, everyone else has heard it. Jorge Aranda and Steve Easterbrook showed in an experiment that an initial figure pulled software estimates toward it (ESEC/FSE, 2005). Choosing in private and revealing together removes the first number.

Disagreement is information. The person with the highest card often knows about work the others have not seen. The person with the lowest may know a shortcut. Cohn's advice is to let those two explain first and to avoid averaging, because the average hides why people disagreed.

It is not a way to beat one expert. In a software project, K. J. Moløkken-Østvold and N. C. Haugen compared tasks estimated with planning poker to tasks estimated by individual experts (Australian Software Engineering Conference, 2007). Group estimates were less optimistic and more accurate than the average of the individual estimates, but the experts working alone were about as accurate as the groups. The practical gain is the shared understanding, not a better number.

How to run a session

  1. Prepare a short list of stories. Each should say who wants what and why, in a few lines. Estimate what you will pull into the next sprint or two, not the whole backlog.
  2. Agree a reference. Pick a finished story and agree on its size. Others are sized against it.
  3. Read a story and take questions. The product owner answers. The team asks what "done" means.
  4. Everyone picks a card face down. No hints, no looks across the table.
  5. Reveal together.
  6. If the cards differ, the highest and lowest explain. Keep it short. Then vote again.
  7. Stop when the team can support one number. Do not average. If three rounds do not converge, park the story: it needs more information, or it needs splitting.
  8. Split stories that draw the top cards. The largest cards mean "this is too big to plan". Cut it into pieces and size those.

Three people, Ana, Ben and Chloé, size "As a user, I can reset my password by email". The first round shows 3, 5 and 13. Ben, who played 13, explains: staging has no email service, and reset links must expire. Ana, who played 3, had assumed the sign-up emails could be reused. Chloé adds that the link expiry needs its own tests. In round two they play 5, 5 and 8 and agree on 5. They also add "Set up email in staging" as a story of its own. The estimate took four minutes and found a missing piece.

Mistakes to avoid

  • Averaging the cards. A 3 and a 13 do not make an 8.
  • Speaking first. A senior person's number sets the room. Keep the cards face down until everyone has chosen.
  • Turning points into hours. "A 5 is one day" defeats the purpose of a relative scale.
  • Estimating without the people who will do the work. In Scrum, the Developers who will do the work are responsible for sizing, according to the Scrum Guide.
  • Long debates. Time-box each story. A long argument means the story is unclear.
  • Estimating everything. Size what will be started soon. Work far in the future changes before you reach it.

When it is the wrong tool

  • For a team of one or two. Talk it through.
  • When the stories are all about the same size. Count the stories instead.
  • For a large backlog. 200 stories is a long afternoon. Size them roughly in T-shirt sizes first, then play poker on the near ones.
  • For unknown work. Research cannot be sized. Set a time limit for it and size what you learn.

In Prior

Prior has a poker table in every Scrum project and in Scrumban projects that add it. Here is how a session runs.

  1. Set up the project. Choose Agile · Scrum under Project type when you create or edit the project. For Agile · Scrumban, open Add a view and choose Planning Poker. Invite your team with Share a project. Owners and editors play, and viewers watch.
  2. Open the Planning Poker tab and Pick the stories. Tick the stories to size, from 1 to 50. Quick selections include Not estimated yet, the active and next sprint, Outside any sprint and All open tasks. Choose the deck and press Start the game.
  3. Invite the table. Each member gets a card, "Alex started Planning Poker", with Join the table.
  4. Play your card. Your hand is at the bottom. Click a card, or type its value: 5, 1 3, ? or C for the coffee card. Cards stay face down, and the table shows "3 of 5 voted". Backspace takes your card back before the reveal.
  5. Reveal. The person running the table presses Reveal cards (Enter). All cards flip together. When votes differ, the lowest and the highest are tagged Lowest and Highest.
  6. Talk, then decide. Re-vote (R) deals another round. Accept 5 points (Enter) writes the value on the task and moves to the next story. When the cards differ, the suggestion is the deck card nearest the average. Use the pencil, Pick another value, to accept what the team agreed instead.
  7. Finish. When every story has an estimate, the table shows the total. Finish session closes it.
A planning poker table with cards revealed
The table: players around the felt, the story in the middle and your hand below.

A few details:

  • Three decks. Fibonacci (0 to 21), Modified Fibonacci (adds ½, 20, 40 and 100) and T-shirt sizes (XS to XL, worth 1, 2, 3, 5 and 8 points). Each also has a Not sure card and a Coffee break card.
  • Nobody can peek. Other players' cards are hidden by the server until the reveal.
  • Too big. Above 13 points, the result turns amber: "21 points: too big for one sprint". Split the task becomes the main action, and Keep 21 points anyway stays available. If your account has Pro, Prior AI proposes the pieces. They become sub-tasks and join the table right after the story. See Split a story.
  • The session menu. The Session button at the top right lists the stories and lets the person running the table jump to one, Skip this task, Split this task or End session.
  • Playing alone. A project that is not shared plays solo: "Playing solo." You walk through the stories and accept each estimate, and Share to play with your team is one click away.
  • No voice. Prior handles the cards, not the conversation. Keep your usual call open.

The full reference is in Planning poker, and the scale is explained in Story points.

Prior

Less noise. More done.