How to Run an Effective Planning Poker Session (Step-by-Step)

A successful planning poker session starts long before anyone picks up a card. The product owner should have a refined set of user stories ready, each with a clear title, description, and acceptance criteria. Stories that are vague or missing context will derail the session as the team spends more time asking questions than estimating.

Aim to bring 15 to 25 stories to each session. Fewer than that and it is not worth gathering the team. More than that and fatigue sets in, leading to sloppy estimates toward the end. If you have a large backlog to estimate, schedule multiple shorter sessions rather than one marathon.

Share the stories with the team at least 24 hours before the session. This lets developers review the work, think about technical approaches, and come prepared with informed perspectives. Teams that estimate cold — seeing stories for the first time during the session — produce lower-quality estimates and spend more time in discussion.

Finally, decide on your estimation scale (Fibonacci is the most common), choose your tool (physical cards or a digital tool like ScrumChamps), and block 60 to 90 minutes on everyone's calendar.

At the start of the session, the facilitator (usually the scrum master) reminds the team of the ground rules. This is especially important for new team members or teams that are still building their estimation practice.

Key rules to establish: We estimate relative complexity, not hours. Everyone votes independently before revealing. The highest and lowest estimators explain their reasoning first. We timebox discussion at five minutes per story. If we cannot converge, we break the story down or flag it for more research.

Also establish what the reference stories are. If your team has been doing this for a while, remind everyone: "Remember, a 3 is about as complex as the search filter feature we built last sprint." New teams should pick two or three recently completed stories as anchors.

The product owner reads the story title and description aloud, then walks through the acceptance criteria. This should take one to two minutes. The product owner's job is to explain what needs to happen, not how — that is the team's domain.

After the presentation, open the floor for clarifying questions. Common questions include: "Does this need to work on mobile?", "Are we building a new component or modifying the existing one?", "What happens if the API call fails?" These questions should be about scope and requirements, not implementation details.

Limit the Q&A to three minutes. If the story generates more questions than answers, it is probably too vague and should be sent back for refinement rather than estimated with low confidence.

Once questions are answered, each team member selects their estimate card. With physical cards, everyone holds their card face-down. With digital tools, each person selects their number privately. The facilitator counts "3, 2, 1, reveal!" and everyone shows their card at the same time.

The simultaneous reveal is non-negotiable. If anyone shows their card early, it anchors the rest of the team. Digital tools enforce this automatically — votes are hidden until the facilitator clicks "reveal." This is one of the key advantages of digital planning poker over informal methods like calling out numbers.

Give the team about 30 seconds to select their cards. If someone is taking much longer, they may be overthinking it. Remind them that story points are rough estimates, not commitments.

After the reveal, scan the votes. If everyone is within one step of each other (say, all 5s and 8s), the team can quickly agree on a number and move on. But if there is a spread of three or more steps (one person plays 2 and another plays 13), that divergence needs exploration.

Ask the lowest estimator to explain first: "You estimated a 2 — what is your approach?" Then the highest: "You estimated a 13 — what are you seeing that others might have missed?" This is where the magic happens. The low estimator might know about a reusable library that saves work. The high estimator might be aware of a database migration requirement that others overlooked.

Keep the discussion focused on the work, not on persuading others to change their vote. The goal is shared understanding, not consensus by social pressure. After two to three minutes of discussion, call for a revote.

After the discussion, vote again. Most of the time, the spread narrows significantly. People who were on the low end adjust upward after learning about hidden complexity. People who were on the high end adjust downward after hearing about available shortcuts or prior work.

If the team converges within one step after the second round, the facilitator picks the higher of the two numbers (err on the side of caution) and records it. If there is still significant disagreement after three rounds, it means the story is not well enough understood. Either break it into smaller stories, assign it to someone for a spike (time-boxed research), or note it as "needs refinement" and move on.

Do not get stuck. The goal is to estimate the entire backlog at a useful level of accuracy, not to achieve perfect consensus on every single story.

Once the team agrees on a number, the facilitator records the estimate and immediately moves to the next story. Keep the pace brisk — spending more than five minutes on any single story yields diminishing returns. If you find yourselves consistently going over five minutes, your stories are probably too large or too vague.

A well-run session should estimate 15 to 25 stories per hour. Track how many stories your team estimates per session and aim to maintain or improve that rate over time. If the rate is dropping, look at whether stories are getting bigger, discussions are getting longer, or the team is experiencing estimation fatigue.

Rotate the facilitator role. Having the same person facilitate every session can lead to that person subtly influencing estimates. Let different team members take turns running the session.

Start with the easiest stories. Warm up with one or two straightforward stories to calibrate the team before tackling complex ones.

Watch for non-participation. If someone always votes with the majority and never speaks during discussions, they may be disengaged or intimidated. Specifically invite quieter members to share their perspective.

Take breaks. After 45 minutes of estimation, take a five-minute break. Mental fatigue degrades estimate quality. If you have more stories to get through, come back fresh rather than pushing through.

End on time. Respect the calendar block. If you do not finish all the stories, the remaining ones go into the next session. Teams that run over consistently will start dreading estimation sessions.