How to run a planning poker session

A planning poker session works when it produces useful estimates without sliding into its second hour. That comes down to three things: prepare the backlog, protect the private-vote-then-reveal mechanic, and time-box hard. Here’s the run of show.

Before the session: refine, then anchor

Most bad sessions trace back to bad prep, not bad facilitation. Two things to settle first.

Refine the backlog. Every story needs clear acceptance criteria, a known owner area (or an explicit cross-cutting flag), and roughly the same level of detail as its neighbours. If half your items are one-line tickets and the other half are multi-paragraph specs, the estimates won’t be comparable, and the session turns into a refinement meeting in disguise.

Pick a reference story. Take one already-shipped story and agree to call it the team’s baseline — a 5, say. Every other estimate is made relative to that anchor. It’s the single cheapest thing you can do to keep a scale stable over time.

Set the ground rules

Say these out loud at the top, especially with new teammates:

1. You’re estimating relative effort, not hours.
2. Don’t reveal a card or say a number aloud until everyone has played.
3. The highest and lowest cards explain themselves. That’s a feature, not a penalty.
4. ? means you genuinely can’t estimate this. ☕ means you need a break.

The four phases of a round

Each story moves through the same short loop.

1. Read and clarify (1–2 min). The facilitator reads the story aloud. Anyone — not just engineers — can ask clarifying questions. The goal is shared understanding, not design. If the room starts solving how to build it, park that and move on.

2. Vote (10–30 sec). Everyone plays a card privately. In a tool the cards stay hidden automatically; in the room, keep them face-down until the reveal.

3. Reveal and discuss (1–4 min). Flip every card at once. If the spread is a single step — all 3s and 5s — take the higher number and move on. If it’s wider, ask the highest and lowest to explain. Nine times in ten you’ll find one of three things: the story isn’t well understood and needs splitting, someone knows about hidden complexity, or someone has done this before and knows it’s smaller than it looks.

4. Re-vote (10 sec). Quick discussion, then re-vote. Most rounds settle in two. If you’re heading for a third, the story needs more refinement or splitting, not more discussion.

Which deck should you use?

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.

Fibonacci (1, 2, 3, 5, 8, 13, 21…) is the default for most teams, and for good reason. The gaps widen on purpose: the bigger the work, the less anyone knows, so the choices spread apart and you decide “8 or 13?” instead of arguing over a 9 versus a 10. The friction is the feature. (More on why Fibonacci.)

Modified Fibonacci adds ½ for trivial-but-trackable work, and 40 and 100 at the top end. The 100 isn’t an estimate — it’s a stop sign meaning “too big to size; break it up first.”

T-shirt sizes (XS–XL) are deliberately fuzzy, which is sometimes exactly right — early refinement, or portfolio-level sizing where the conversation is about scope, not sprint capacity. The catch: T-shirts don’t add up, so they can’t feed a velocity number.

Powers of two (1, 2, 4, 8, 16…) suit engineering teams that already reason in doublings; the jumps get aggressive fast, which is the point.

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.

The special cards: ?, coffee, and 100

A few cards aren’t numbers, and each carries real information:

• ? — I can’t estimate this. A stop sign, not a shrug. It usually means the team is missing context, or the story isn’t defined enough yet. Surface it; don’t wave it through.
• ☕ — I need a break. Take it at face value. Estimation fatigue tanks the quality of every round that follows, and five minutes is cheaper than a bad sprint.
• 100 — this is too big to estimate. A flag, not a number. Don’t talk yourselves down to a 40 to dodge the refinement work; split the story instead.

Time-box the session, not just the stories

Per-story time-box: three to five minutes. Session time-box: 30 to 45. When you hit either, ship the current estimate or punt the story back to the backlog. Teams that know you’ll actually enforce the box prepare better for next time. If there’s a long tail of items to size, don’t grind through it here — reach for a faster technique like bucket sizing.

Running remote and hybrid sessions

Run the session over video — you want tone of voice and the visual cue of someone about to speak. Use a planning poker tool to keep votes genuinely hidden; the honour system in a chat thread is an anchoring accident waiting to happen. TeamRetro’s free planning poker hides every card until the reveal, so a distributed team gets the same mechanic as one gathered around a table.

New to the technique? Start with what planning poker is. Already fluent, and want to know where it goes wrong? Planning poker mistakes is the field guide.

Frequently asked questions

What are the steps in a planning poker session?

Refine the backlog and pick a reference story first. Then, for each item: the facilitator reads it and the team clarifies, everyone votes privately, all the cards are revealed at once, and the highest and lowest cards explain any wide spread before a re-vote. Most items settle within two votes.

How long should a planning poker session last?

Time-box the session to about 30 to 45 minutes and each story to three to five. Estimation quality drops sharply past 45 minutes as people tire and start playing whatever the lead plays. If there is more backlog to size, schedule a second session or switch to a faster technique.

Which planning poker deck should we use?

Start with Fibonacci — 1, 2, 3, 5, 8, 13 — for most sprint work; it has enough granularity to plan with and enough friction to keep arguments short. Move to modified Fibonacci when you want to flag oversized stories, and to T-shirt sizes for early, roadmap-level sizing where the numbers do not need to add up.

What do the ? and coffee cards mean?

The question-mark card means someone genuinely cannot estimate the story yet — treat it as a stop sign that the item needs more context, not as a non-vote. The coffee card means someone needs a break; take it seriously, because a tired room produces worse estimates every round after.

What is a reference story?

A reference story is one already-shipped story the team agrees to treat as a fixed baseline — a 5, say — so every other estimate is made relative to it. Without an anchor, the meaning of a 5 drifts sprint to sprint and the resulting velocity becomes a random walk.