Most planning poker sessions fail before the first card is played. Someone drops twelve half-written stories into a call, the team squints at them, and the next ninety minutes turn into a slow negotiation where the loudest voice sets every number and everyone else nods along while checking Slack.
That's not a poker problem. That's a preparation problem wearing a poker costume. The technique itself is one of the better ideas agile ever produced: everyone estimates independently, reveals at the same time, and the disagreements surface information the team didn't know it had. Done well, a session moves fast and people leave with a shared understanding of the work. Done badly, it's the meeting everyone quietly resents.
Here's how to run one that earns its slot on the calendar.
Do the prep, or don't bother
A story is ready to estimate when someone who didn't write it can read the acceptance criteria in under a minute and roughly picture the work. That's the whole bar. Not a full spec. Not a design document. One minute of reading.
If a story fails that test, estimating it is theater. The team will vote on their individual guesses about what the story means, the numbers will scatter, and you'll burn ten minutes discovering that nobody agrees on the scope. You could have found that out in refinement for free.
So before the session, the product owner or whoever grooms the backlog should walk the candidate list and ask one question per story: could a developer read this cold and know what "done" looks like? Stories that don't pass go back to refinement. Be ruthless about this. A session with six well-refined stories beats a session with fifteen vague ones every single time.
Who's actually in the room
Everyone who might build the work votes. Developers, testers if they're embedded in the team, whoever will touch the story. The product owner attends to answer questions but doesn't vote; they're estimating value, not effort, and mixing the two muddies both.
Keep the list short beyond that. Every extra person in the room adds clarifying questions, side conversations, and social pressure. If someone won't do the work and can't answer questions about it, they're an observer, and observers change votes in ways I'll get to later.
Running a round
The mechanics are simple and the simplicity is load-bearing.
Someone presents the story. Ideally the product owner gives a short summary rather than reading the ticket aloud word for word; people can read. Then a brief window for clarifying questions. Questions about what the story means are fair game. Debates about how to build it are not, at least not yet. If the questions run past a couple of minutes, that's your signal the story wasn't ready.
Then everyone votes. Silently, simultaneously, no exceptions. Each person picks a card and nobody sees anyone else's choice until every vote is in. Then the reveal, all at once.
The simultaneous part is the entire point of the exercise, and it's the first thing teams break. Picture a refinement call where the most senior engineer glances at a story and says "eh, that's a three" before anyone has voted. The round is over. It doesn't matter what anyone privately thought; almost nobody will now play an eight and publicly disagree with the person who reviews their pull requests. Anchoring isn't a character flaw, it's how brains work, and the only reliable defense is making sure no number gets spoken before the cards turn over. If you're doing this in person, physical cards flipped together work fine. If you're remote, use a planning poker tool that keeps votes hidden until everyone has committed. Do not vote by typing numbers into chat. The first number in the channel anchors every number after it.
Talk about the gaps, not the numbers
The reveal is where the value lives, and specifically where the votes disagree.
If everyone played a five, congratulations, write down five and move to the next story. Consensus needs no discussion. The interesting case is a spread: someone played a two, someone played a thirteen, everyone else clustered around five.
Resist the urge to open the floor. Instead, the highest and lowest voters explain first, and everyone else stays quiet until they've spoken. Almost always, one of two things comes out. Either the high voter knows something the room doesn't ("that endpoint touches the legacy billing code, and everything that touches billing takes three times longer than it should") or the low voter does ("we built almost exactly this for the export feature, it's mostly copy and adapt"). Both are gold. Both would have stayed buried if the team had just averaged the votes and moved on.
Then you re-vote. Same rules, silent and simultaneous. Most spreads collapse on the second round because the missing information is now shared.
Know when to stop
Two rounds is usually enough. If the second vote converges, done. If it lands within one step, say a split between five and eight, take the higher number and move on. Seriously. Just take the higher one.
Teams lose more time to this than to anything else in estimation. Ten minutes of debate over whether a story is a five or an eight is ten minutes spent arguing inside the margin of error. The gap between adjacent cards exists precisely because estimates get fuzzier as work gets bigger, which is why estimation decks use the Fibonacci sequence instead of a neat linear scale. The deck is telling you the difference is noise. Believe the deck, round up, next story.
The exception worth honoring: if two rounds pass and the votes still span three or more steps, stop estimating. That story has an unresolved question inside it, and no amount of card-playing will answer it. Park it, write down the open question, and send it back to refinement. This isn't a failure of the session. It's the session doing exactly its job, which is surfacing the stories the team doesn't understand yet before they land in a sprint and explode.
The observer problem
A quick word on managers who "just want to sit in." Votes change when someone with influence over reviews or promotions is watching. Estimates drift low because nobody wants to look slow, and the honest "this scares me, thirteen" votes quietly disappear. Then the sprint overruns and the same observer wants to know why the estimates were wrong.
If a stakeholder genuinely needs visibility, share the outcomes afterward. If they insist on attending, set the ground rule explicitly: no reactions to individual votes, no "really? that seems high." It depends on your culture whether that rule holds. In plenty of teams it doesn't, and the honest move is to keep the room to the people doing the work.
Timeboxing that actually holds
Budget about five minutes per story, all in: presenting it, questions, two voting rounds, and the outlier discussion. Easy stories take ninety seconds and buy back time for the hairy ones. If a story blows well past the budget, that's the parking signal again.
A healthy 60-minute session looks roughly like this:
- Five minutes to settle in and restate the scale, especially if the team is new to it.
- Forty-five to fifty minutes of estimation, covering eight to twelve stories.
- A few minutes at the end to review what got parked and who owns the follow-up questions.
Which means the team that schedules thirty stories for one sitting has already lost. Around the forty-minute mark, decision fatigue sets in and every estimate quietly becomes a five because fives end conversations. The numbers from the back half of a marathon session aren't estimates, they're surrender. Cap the list. If the backlog genuinely needs thirty stories estimated, that's three sessions across a week or two, not one afternoon of diminishing returns.
For remote teams the mechanics barely change: same silent vote, same reveal, same outlier-first discussion, just with a tool doing the card handling. You can create a room in ScrumMastr in a few seconds and run the round exactly as described above. The one real variant worth knowing is async estimation, where votes trickle in over a day and only the stories with big spreads get a live conversation. It trades energy for flexibility and suits teams straddling many time zones. Remote and async estimation have enough of their own failure modes that they deserve their own article, so I'll leave the details there.
Check your work occasionally
One habit separates teams that estimate well from teams that just estimate: every few sprints, pull up a handful of finished stories and compare the number you played against how the work actually went.
Not to grade anyone. Estimates are guesses and guesses miss. The point is calibration. You'll notice patterns, like every story touching the auth service running heavy, or the long five-versus-eight debates predicting nothing at all. Feed that back into the next session and your numbers slowly get more honest.
That's the quiet payoff of doing poker properly. The points were never really the product. The product is a team that has argued about the work before doing it, found the traps early, and walks into the sprint with fewer surprises. The cards are just a good excuse to have that argument.