How to run a planning poker session

If you are new to the technique, read what is planning poker first. If your team is distributed, pair this with the guide to planning poker for remote teams. This page assumes you know the basics and want to run a session well.

Before the session

Most sessions that run long were lost before they started. The prep is short but it matters:

• Refine the backlog first. Estimation is not the place to discover that an item has no acceptance criteria. Items should be clear enough that the team can size them after a sentence or two of context. Anything that still needs designing is not ready to estimate.
• Queue the items in advance. Decide which items you are estimating and in what order, so the session flows from one to the next instead of stalling while everyone hunts for the next ticket.
• Decide who votes. The people who will build the work estimate it. Stakeholders and the product owner attend as observers to give context, not to vote.
• Pick the deck. A Fibonacci-like sequence is the common default. Agree on the scale before you start so nobody is quietly using a different one.

Setting up the room

Whether you are around a table or in an online room, three roles keep a session clean:

• The facilitator runs the process. They present items, keep discussion timeboxed, call the reveal, and record the agreed estimate. Crucially, they run the process, not the estimates: a facilitator who argues for a number has stopped facilitating.
• The voters are everyone who will do the work. Each holds the deck and votes on every item.
• The observers are the product owner and any stakeholders. They present items and answer questions, then sit out the vote so they don't anchor it.

In an online room, set these roles up front. Marking the product owner as an observer, for example, keeps them in the conversation without their card weighing on the result.

Running a round

1. Present the item. Someone who knows it, usually the product owner, explains it in a sentence or two. The team asks clarifying questions. Keep this short.
2. Everyone votes privately. Each voter picks a card without seeing the others. A short delay before the reveal is unlocked gives people a moment to actually think rather than copy the first vote in.
3. Reveal together. All cards flip at once. Letting the reveal happen automatically once everyone has confirmed removes a repetitive click and a beat of dead time.
4. Read the spread. If the numbers agree, record the estimate and move on. If they don't, that gap is the point of the exercise.
5. Discuss and re-vote. The highest and lowest estimators explain their reasoning, the team absorbs it, and everyone votes again.
6. Finalize. Record the agreed number and pull the next item from the queue.

Handling disagreement

A spread of estimates is not a failure of the session; it is the reason the session exists. It almost always means people are imagining different work. One person assumed an existing component could be reused; another knew it has to be rebuilt. Surfacing that gap before the sprint is worth far more than the number itself.

The move is always the same: the outliers explain, the team learns something, and you vote again. But don't let a single item become a black hole. After two or three rounds without convergence, either take the higher estimate and move on, or treat the stubborn disagreement as a signal: the item is probably too large or too vaguely defined, and should be split or clarified before anyone commits to it.

The special cards

Most decks carry two cards that aren't numbers, and both are worth taking seriously when they appear:

• The question mark means "I can't estimate this without more information." Several of them on one item is a clear sign it needs refining, not estimating. Send it back.
• The coffee cup means "I need a break." A session past the hour mark produces worse estimates, not more of them. Take the break.

Keeping the pace

The most common way a session fails is not bad estimates; it is losing the room to a session that drags. A few rules protect it:

• Timebox discussion per item to a few minutes, and park anything that turns into a design debate.
• Estimate one item at a time so the team's attention has a single focus.
• Keep the whole session to sixty to ninety minutes; split a large backlog across several shorter sessions.
• Don't re-litigate finalized items. Once a number is recorded, move on.

After the session

The estimates you just made are story points: relative sizes, not hours and not deadlines. Over a few sprints, the team's measured velocity turns those points into a calendar forecast far more reliably than any up-front hour guess. Resist the pull to convert points to hours or to treat an estimate as a commitment. The moment estimates become promises, people learn to inflate them, and the honest signal you just worked to get is gone.

Common questions

Who should facilitate a planning poker session?

Usually the scrum master or team lead, but it does not have to be a fixed role. The facilitator runs the process rather than the estimates: they present items, keep discussion timeboxed, and call the reveal. They should not push the team toward a particular number.

How long should a planning poker session last?

Keep it to sixty to ninety minutes at most. Attention fades after that, and estimates made by a tired team are worse, not more thorough. If the backlog is large, run shorter sessions more often rather than one long marathon.

How many items can you estimate in one session?

With discussion timeboxed to a few minutes each, a team can usually estimate ten to twenty items in an hour. Well-refined items that the team already understands go faster; vague ones eat the clock and are a signal to refine before estimating, not during.

What do you do when the team can't agree on an estimate?

Have the highest and lowest estimators explain their reasoning, then vote again. Most items converge within two or three rounds. If one does not, either take the higher number and move on, or treat the persistent spread as a sign the item is too big or too vague and should be split or clarified first.

Should the product owner vote?

No. The people who will build the work do the estimating, because size and complexity are theirs to judge. The product owner presents the item and answers questions, then watches as an observer. Their job is to clarify scope, not to influence the number.

Run your next session here

Point Taken is a free planning poker room built for exactly this: an item queue to work through, roles for voters and observers, an optional reveal timer and auto-reveal to keep the pace, and a record of what the team estimated. No sign-up, no ads, no tracking. Open a room, share the link, and start with your next backlog item.