Planning poker: how to run it well (remote-friendly guide)

How to run planning poker well, in person or online: Fibonacci cards, avoiding anchoring, handling outliers, when not to estimate, and t-shirt sizing instead.

By Evan, AIYUN · Updated 2026-10-29

Planning poker is a simple way for a team to estimate work together. Everyone picks a card in private, all cards are revealed at once, and the team talks about the differences. The number matters less than the conversation it forces: if one person says 2 and another says 13, you have just found a misunderstanding before it cost you a sprint.

This guide covers how to run it well, especially when your team is remote.

EstimateLift · Estimate the backlog together and leave with numbers you can paste into Jira.

Try it free

Where planning poker comes from

James Grenning described planning poker in 2002 as a way to stop estimation meetings dragging on. Mike Cohn later popularised it in his book Agile Estimating and Planning (2005). It builds on the older Wideband Delphi idea: independent estimates first, then discussion, then re-estimate.

How it works, step by step

In planning poker, the product owner reads a backlog item, the team asks clarifying questions, then everyone picks an estimate card in private and all cards are revealed at once. If votes are close, take the common value; if they are far apart, the highest and lowest voters explain and the team re-votes.

1. Read the story. The product owner explains the backlog item and the acceptance criteria. Keep this to a minute or two.
2. Ask questions. The team clarifies anything unclear. Do not discuss sizes yet.
3. Everyone votes privately. Each person picks a card without showing it.
4. Reveal at the same time. All cards flip together.
5. Discuss the spread. If votes are close, take the common value and move on. If they are far apart, the highest and lowest voters explain their thinking.
6. Re-vote once or twice. Usually the team converges by the second round. If not, see "handling outliers" below.

Which card deck to use

Most teams use a modified Fibonacci sequence:

0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, ☕

The gaps grow on purpose. Estimates get less precise as work gets bigger, and the deck reflects that. Nobody can honestly tell the difference between a 14 and a 15, but they can tell 8 from 13.

• ? means "I do not understand this well enough to estimate". Treat it as a signal to clarify, not a failed vote.
• ☕ means "I need a break". Respect it. Estimation fatigue produces bad numbers.
• Anything above 13 usually means "split this story" rather than "this is a 40".

Avoiding anchoring

Anchoring is the reason planning poker uses private votes. If a senior engineer says "this is about a 3" before anyone votes, most of the room will drift toward 3. Their guess might be right, but you have lost everyone else's information.

Ways to prevent it:

• No numbers out loud before the reveal. The facilitator should step in gently if someone says "it's just a small one".
• Reveal simultaneously. In a physical room, count down and flip. Online, use a tool that hides votes until everyone has voted.
• Show who has voted, but never what they voted, until the reveal.
• Ask the product owner not to vote. Their job is to answer questions about value and scope, not effort.

Handling outliers

An outlier is the most useful thing that can happen in planning poker. Someone knows something the others do not, or has misunderstood something the others assumed.

When votes are far apart:

1. Ask the highest and the lowest voter to explain, briefly, with no judgement. "What were you thinking about?" works well.
2. Listen for hidden work: testing, data migration, a dependency on another team, an unfamiliar part of the codebase.
3. Re-vote.
4. If you still cannot agree after two rounds, do one of three things: take the higher estimate, split the story, or park it and add a short spike to find out more.

Avoid averaging. If three people say 3 and one says 13, the answer is not 5.5. The answer is a conversation about what the 13 person saw.

Running planning poker online

Remote estimation works well once a few basics are in place:

• Load the backlog in advance. Pasting a list of Jira keys or a CSV saves ten minutes of "which ticket are we on?".
• Try async pre-voting. For teams across time zones, say Brisbane and Auckland, people can vote on straightforward stories before the meeting. You then only meet to discuss the ones with a spread.
• Keep cameras on during discussion. Faces help you notice when someone disagrees but has not said so.
• Export the results. Copying numbers back into Jira by hand is where mistakes creep in.

EstimateLift works like other planning poker tools but is built around these habits: paste Jira keys or a CSV, vote privately, reveal together, see outliers called out, pre-vote asynchronously, split stories on the spot, and export back to Jira. It also supports t-shirt sizing and function points. It is free, made by AIYUN, and needs no accounts.

T-shirt sizing: the lighter alternative

For early roadmap work or a large backlog you have never seen before, story points can be too fine-grained. T-shirt sizing uses XS, S, M, L, XL instead.

A common pattern is to t-shirt size everything in a quarterly planning session, then use story points only for the items coming into the next couple of sprints.

When not to use planning poker

Planning poker is a tool, not a ritual. Skip it when:

• The work is very similar in size. If most stories are about the same size, counting stories may forecast just as well as points.
• The team is not doing the work. Estimates should come from the people building the thing, not from a manager or a separate analysis team.
• The numbers are used to judge people. If points are compared across teams or tied to performance reviews, they will inflate and stop being useful.
• The work is pure discovery. You cannot estimate "find out why checkout conversion dropped". Timebox it instead.
• You are estimating to fill a spreadsheet. If nobody uses the numbers to plan, stop producing them.

Tips for a better session

• Keep sessions under an hour. After that, quality drops.
• Agree on one or two reference stories ("this login change was a 3") so the scale stays stable over time.
• Estimate effort, complexity and uncertainty together, not hours.
• Let the team re-estimate if they learn something big mid-sprint, but do not chase perfect numbers.
• Make sure the stories are ready before the session. Estimating a one-line ticket wastes everyone's time.

Frequently asked questions

EstimateLift · Estimate the backlog together and leave with numbers you can paste into Jira.

Try it free