Person holding playing cards on a white table

Photo by Andrik Langfield on Unsplash

How to Choose a Planning Poker Deck That Fits Your Team

Compare the four standard decks, pick one with three questions and review the choice after a few sprints.

Estimation Cleiton Loiola · · 9 min read

Your team starts a planning poker round, and the cards are already there: 1, 2, 3, 5, 8, 13. Nobody on the team chose them. They came with the tool, with the last team or with an old training course. You vote, you talk about whether the story is a 5 or an 8, and you move to the next story.

Many teams use Fibonacci by default and never ask if it fits their work. A planning poker deck is the set of values that each person can vote with. It shapes the conversation before anyone plays a card. This article looks at what the card values do, compares the four standard decks, gives you a simple way to pick one and shows you how to review your choice.

First, two terms. Story points are a relative measure: you compare a story with other stories, not with hours. Velocity is the number of story points that your team completes in one sprint.

No deck is correct for every team. Choose the deck that fits your work and your team's experience, and write down why you chose it. Then check the choice again after a few sprints.

What the numbers on the cards actually do

The values on your cards decide which differences your team can argue about. TeamRetro's guide to running planning poker puts it this way: "The numbers on the cards shape how the team thinks about effort, so choosing a deck is part of the work, but you don’t need to overthink it." Both halves of that sentence matter. Choose with care, but do not turn the choice into a project.

Close numbers are hard to tell apart

Imagine a deck with every number from 1 to 10. A story could be a 6 or a 7. Nobody can really tell the difference, so the discussion goes around in circles. Mike Cohn of Mountain Goat Software states the problem directly: "numbers that are too close to one another are impossible to distinguish as estimates."

When the values are too close, your team spends time on differences that nobody can measure. Engineers feel pushed to defend a number they cannot support, and the scrum master has to stop a debate that has no useful answer.

Gaps that grow on purpose

In a Fibonacci-type deck, the gap between values grows as the numbers grow. Small work gets fine steps, such as 1, 2 and 3. Big work gets coarse steps, such as 13, 20 and 40. This is deliberate: bigger work has more unknowns, so a number that looks exact would claim more than the team knows.

Cohn saw this problem on his own teams. They learned that an estimate of 21 story points implied a precision that they could not support. That matters for the product owner and for anyone else who reads estimates, because a number that looks exact can look more certain than it is.

No sequence is proven to be the best

Do not expect research to pick your deck for you. Cohn's teams used both a modified Fibonacci sequence and a doubling sequence. His conclusion: "Each worked equally well. Most teams had a strong preference for one or the other, but I could find no clear evidence that either sequence was better than the other."

So treat all deck advice as a starting point, including the advice in this article. The deck is a team agreement, not a law. The aim is a scale that your team understands and uses the same way each time.

Try it with your team

Use this short exercise in your next refinement session. Take a real story from your backlog. Show the team two pairs of values: 3 and 4, then 5 and 8. Ask which pair is easier to choose between for this story.

Then ask what a vote of 4 tells you that a vote of 3 does not. The answers show whether close values help your conversation or only slow it down. The exercise takes about five minutes, and everyone in the room can take part.

The four standard planning poker deck types and when each fits

Each standard deck balances detail against honesty about uncertainty in a different way. Here is a short, fair view of each. Note that two of the three sources in this article are guides from agile tool vendors. Their advice is useful practice, but it is opinion, not proof.

Fibonacci: 1, 2, 3, 5, 8, 13, 21

The values widen on purpose, so your team chooses between 5 and 8, not between 6 and 7. The deck suits sprint-level work, where you want numbers that you can add up and compare across sprints. Many teams use it because it is familiar. That is a good reason only if the deck also fits the work.

Modified Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40, 100

This deck rounds the larger values, so a big story does not look more exact than it is. The top card also has a special job. The TeamRetro guide says that the 100 is not an estimate. It is a stop sign: the story is too big to size, and the team must break it up first.

That makes modified Fibonacci useful when your team wants a clear way to flag stories that are too big. The product owner gets a direct signal to split the story before the next round.

T-shirt sizes: XS, S, M, L, XL

Letters remove the false look of precision. Scrumpoker-Online's story points guide says that T-shirt sizes are good for early roadmap-level sizing, where numbers would suggest an accuracy that nobody has. The TeamRetro guide agrees. It calls T-shirt sizes deliberately fuzzy and says they fit early refinement or portfolio-level sizing, where the conversation is about scope, not sprint capacity.

The cost is clear: you cannot add letters together. Scrumpoker-Online notes that this makes T-shirt sizes less useful for sprint planning, because you cannot sum letters into a velocity. If your team or your stakeholders need a total, T-shirt sizes alone will not give you one.

Powers of 2: 1, 2, 4, 8, 16, 32

Each card is double the card before it. This can feel natural to teams that already think in doublings. But Cohn saw a side effect: with a doubling scale, all discussions about user stories were about whether something was double or quadruple the size.

If you use this deck, listen to your discussions. Do they stay on the work in the story, or do they turn into a debate about ratios? If you often hear the second pattern, try a different deck for a few sprints.

Where the sources disagree

The sources do not agree on a default deck for new teams. The TeamRetro guide says: "Starting fresh? Use Fibonacci. Switch to T-shirts only if you catch the team debating single-point differences, and to modified Fibonacci once you want to flag oversized stories explicitly."

A reasonable alternative is to start with T-shirt sizes. A new team has no shared sense yet of what a 5 means, and letters do not pretend that it does. Both positions are reasonable, so make this a team choice.

A starting table

Use this table as a starting point, not as a rule.

Your situation Suggested starting deck Why
New team Fibonacci or T-shirt sizes Fibonacci gives you numbers to add up from the start. T-shirt sizes avoid false precision while the team builds a shared reference.
Roadmap triage or early refinement T-shirt sizes The conversation is about scope, not sprint capacity.
Sprint planning Fibonacci or modified Fibonacci You can add the values up, and the gaps widen with size.
High uncertainty or many stories that are too big Modified Fibonacci, or T-shirt sizes for early items The 100 card flags work that is too big to size. Letters avoid numbers that look exact.
Team already thinks in doublings Powers of 2 The deck matches how the team thinks. Watch for debates about ratios.

A simple way to pick a deck for your team

Pick the deck by answering three questions together, not by habit. The scrum master or delivery lead usually runs this conversation, and the product owner and the engineers each bring an answer that matters.

Ask three questions

  1. Who reads the estimate? If only the team uses it to plan a sprint, numbers work well. If stakeholders read it for a roadmap, coarse sizes can give a more honest message.
  2. How well do you understand the work? Well-refined stories can take finer values. Early ideas with many unknowns need coarse values.
  3. Do you need to add the numbers up? If you track velocity or plan sprint capacity, you need numbers. Letters do not add up.

The product owner usually knows the answer to the first question best, and the engineers know the most about the second. The whole team owns the third, because it decides how you plan.

Choose a starting point

Use your answers to pick a starting deck:

  • New team or early roadmap items: T-shirt sizes, or Fibonacci if you want numbers from the first sprint.
  • Sprint-level work: Fibonacci or modified Fibonacci.
  • Teams that think in doublings: powers of 2.

Coarse sizes fit best in early refinement. If your team refines and sizes stories in the same session, read our guide on how to run a backlog refinement meeting that ends on time. A clear deck choice keeps that meeting shorter, because nobody has to argue about the scale itself.

Make a custom deck only for a clear reason

A custom deck is any set of values that your team agrees on. Make one only when you can give the reason in one sentence. Scrumpoker-Online gives two examples: some teams cap their scale at 8, so anything bigger gets split, and other teams add a coffee-cup card for a break.

A cap at 8 sends a clear signal. If a story does not fit, the next step is to split it, not to argue about a large number. A break card lets people ask for a pause in a long session without stopping the round to explain.

Avoid custom decks that add close values back in, such as 4, 6 and 7. They bring back the problem from the first section. If you cannot explain why your team needs a value, leave it out.

Keep the same deck long enough to compare

Once you pick a deck, stay with it. Scrumpoker-Online puts it plainly: "Which scale you pick matters less than using the same one consistently. Velocity only works if a 5 this sprint means the same as a 5 last sprint."

If you change the deck every sprint, your numbers lose their meaning, and you can no longer compare one sprint with the next. Give the deck enough sprints to show how it works for your team.

A 10-minute team exercise

Run this exercise at the start of a refinement session or a retrospective:

  1. Show the three questions (1 minute). Put them on a shared screen or a whiteboard.
  2. Answer silently (3 minutes). Each person writes their own answers. Silent answers first stop the loudest voice from setting the result.
  3. Share (4 minutes). Each person reads their answers. Note where the answers agree and where they do not.
  4. Agree (2 minutes). Choose one deck and write one sentence that explains why.

Here is an example sentence: We use modified Fibonacci because we plan by sprint capacity and we want a clear flag for stories that are too big. Keep the sentence where the team can find it later.

Set the deck in the room, then review it after a few sprints

A deck choice only helps if everyone votes with it and the team checks it later. Set it before you start, and review it with a short checklist.

Set the deck before the round

The facilitator sets the agreed deck before the first story, not halfway through a session. Write the reason next to it, in your team agreement, wiki or refinement notes. A new team member can then learn the scale from the reason instead of guessing.

If you run planning poker online, make sure that your tool supports the deck that you chose. TinyTroop is free online planning poker with Fibonacci, modified Fibonacci, T-shirt, powers of 2 and custom team decks, and it has a storybook look and card flips. Votes stay secret until the reveal, and the reveal shows the average, the median, the spread and the consensus. The tool runs the round, but your team still owns the practice of choosing and reviewing the deck.

Review the deck after three sprints

After about three sprints, add a short deck check to your retrospective. Use these four questions:

  1. Are we stuck on one-step debates? If the team often argues between two values that are next to each other, the scale may be too fine, or the stories may not be clear enough. The TeamRetro guide names this pattern as the signal to switch to T-shirt sizes.
  2. Do we use the top cards? If people play the largest cards often, many stories are too big, so split them before you estimate. If nobody plays them, ask if the team understands what they mean.
  3. Do people still understand the scale? Ask a team member to explain what a 5 means for your team. If the answers differ, agree a reference story again.
  4. Do our votes split widely on the same kind of story? A wide spread can mean that the scale or the story needs a closer look. Use our guide to hear the outliers when planning poker votes split to find out which.

Keep the review short; ten minutes is usually enough. Write down the answers so that you can compare them at the next review.

Change the deck with care

Change the deck only when the team agrees, and only for a reason that you can write down. When you change it, keep the old estimates in context: a 5 on the old deck does not mean a 5 on the new deck. Mark the sprint where the change happened, so that nobody compares old and new numbers as if they were the same.

Do not expect a new deck to make your estimates more accurate or your team faster. None of the sources in this article shows that. The deck shapes the conversation, and the conversation is where your team finds the useful information.

Your takeaway

Pick the deck that fits three facts: who reads your estimates, how well you understand the work and whether you need to add the numbers up. Write one sentence that explains the choice. Review it at the retrospective after three sprints, and change it only by team agreement.

Ready to try your chosen deck with the whole team? Start a free room, share the link and run your next estimation round with the deck you agreed.