How to run a Planning Poker session

Voters are the people who will do the work: developers, testers, designers… They estimate because they know the real effort involved.

• The facilitator (often the Scrum Master) runs the session, keeps time and reveals the cards. They can vote if they are part of the delivery team.
• The Product Owner presents the stories and answers business questions. They usually don’t vote, so as not to steer the estimate.
• Observers (managers, stakeholders) can follow the session without voting.

A good session is won before it starts. The Product Owner picks the stories to estimate, ideally the highest-priority ones in the backlog, and makes sure each one has a clear title, a description and acceptance criteria.

• Share the list of stories a day or two in advance so the team can read through it.
• Pick the deck: the Fibonacci sequence for story points, t-shirt sizes for a rougher estimate.
• Agree on a reference story, already delivered, that everyone knows. It is your yardstick: “is this bigger or smaller than story X?”.
• Plan for 45 minutes to an hour. Beyond that, attention drops and so does the quality of the estimates.

1. 1The Product Owner presents the story: the need, the expected value, the acceptance criteria.
2. 2The team asks questions to clarify the scope, without talking numbers yet.
3. 3Everyone picks a card in secret. Nobody says their value out loud.
4. 4The facilitator reveals all the cards at the same time.
5. 5If the votes converge, the estimate is recorded. Otherwise, the team discusses and votes again.

The simultaneous reveal is the heart of the method: it prevents anchoring, where the first number spoken (often by the most senior person) sways everyone else.

A big gap, say a 2 and a 13 on the same story, is not a problem: it shows the team doesn’t share the same understanding of the work. That is exactly what Planning Poker is meant to surface.

• First ask the outliers (the lowest and highest votes) to explain their choice. Often one of them spotted a difficulty the other missed, or the other way around.
• After the discussion, vote again. Two or three rounds are usually enough to converge.
• If the team still doesn’t converge, go with the majority value, or the highest one to be safe, and move on.
• If the story is still unclear, don’t estimate it: send it back to the Product Owner to be clarified or split.

The “?” card means there isn’t enough information to estimate, and the “☕” card that a break would be welcome. Take them seriously: they say a lot about how the session is going.

• Letting the Product Owner or a manager vote: their opinion carries more weight and biases the team.
• Saying a number before the reveal (“I’d say 5…”), which defeats the point of the secret vote.
• Arguing endlessly over a 3 versus a 5: an estimate doesn’t need to be perfect, just useful.
• Converting story points into hours or days. Points measure relative effort, not time.
• Comparing points across teams: each team has its own scale.
• Estimating stories that are too big. Beyond 13, the story should be split.

Copy the estimates into your tracker (Jira, Azure DevOps, Linear…): with The Planning Poker, the session summary exports as CSV. Over the sprints, compare planned and completed points to measure the team’s velocity and make future planning more reliable.