A good planning poker session takes 30 minutes and leaves everyone aligned. A bad one takes two hours and leaves everyone exhausted with numbers that don't reflect reality. The difference is almost always process, not people.
Here's how to run one that actually works.
Before the session: get your stories ready
Planning poker only works when the stories are estimable. That means each item in the backlog needs at minimum:
- A clear description of what the user wants to achieve
- Defined acceptance criteria — how will you know it's done?
- No hidden dependencies that haven't been discussed
If you can't answer "what does done look like?", don't estimate yet. Refinement comes before estimation. Stories that aren't ready get a special card: a question mark. That's a valid answer.
Step 1 — Pick a moderator
Typically the Scrum Master or Product Owner, but anyone works. The moderator's job is to read the story, manage the discussion, and keep the session moving. They should not influence estimates — if they're voting too, they should vote silently like everyone else.
Step 2 — Present the story, answer questions
Read the story aloud. Let the team ask clarifying questions — but keep this phase short. You're not looking for a complete design discussion, just enough shared understanding to place a number. A good rule: if a question takes more than two minutes to answer, the story probably needs more refinement before it can be estimated.
Time-box the discussion. Set a visible timer. 2 minutes of questions before voting, then 3 minutes of discussion after the reveal. People talk more efficiently when they can see time passing.
Step 3 — Everyone votes simultaneously
Each team member picks their card — privately, without showing anyone. Then everyone reveals at the same time. This is non-negotiable. If you let people show their cards one by one, the first number anchors every vote that follows.
With a planning poker tool like PlanPok, the reveal is instant and simultaneous regardless of where your team members are sitting — or which timezone they're in.
Step 4 — Discuss the outliers
You'll almost always have at least one outlier. Ask the highest and lowest voters to explain their reasoning. Don't ask everyone — just the extremes. The goal isn't to justify your number, it's to share the context you had in mind that others might have missed.
Common reasons for outliers:
- One person knows about technical debt in that area that others don't
- Someone has done this before on another project and knows the hidden traps
- The low voter interpreted the scope more narrowly than intended
These conversations are the point of the exercise. The estimate is a byproduct.
Step 5 — Re-vote until consensus
After discussion, vote again. Most stories reach consensus in round two. If you're on round three with no convergence, one of two things is happening: the story is too big (split it), or there's a fundamental disagreement about scope (clarify it with the Product Owner before estimating).
Consensus doesn't mean everyone agrees exactly. It means everyone can live with the number. A spread of 5 and 8 that lands on 8 after discussion is fine. A spread of 3 and 21 that's still there in round three is not.
Running planning poker remotely
Remote planning poker works well when you have the right tool. The key differences from in-person sessions:
- Use video, not just voice. Seeing faces during the reveal makes the discussion feel more like a conversation and less like a meeting.
- Keep sessions shorter. 45 minutes maximum. Remote sessions are more tiring than in-person ones.
- Appoint a timekeeper. Without a physical room to read the energy, it's easier to let discussions run long.
- Encourage everyone to vote. Remote settings make it easier for quieter team members to skip a round. Call them in gently if they haven't voted.
Common mistakes to avoid
Estimating too many stories in one session. Five to ten items per session. Beyond that, estimates degrade fast.
Letting the PO vote. The Product Owner clarifies scope — they shouldn't influence the effort estimate. Many teams ask the PO to abstain from voting.
Averaging instead of discussing. If you get a 3 and a 13 and split the difference to an 8, you've missed the point. Someone saw something. Find out what.
Confusing story points with hours. They're not the same. Story points measure relative complexity. Velocity will tell you how many points your team can deliver per sprint over time — but that takes a few sprints to calibrate.