How to play planning poker, step by step

Before you start: what to prepare

Planning poker works when the story arrives described, not when the team finds out what it is at vote time. Before opening the room, make sure of three things: the backlog item with context and acceptance criteria, the people who build it in the room and a place to record the number at the end.

It also pays to allow a few minutes of silent reading before the vote: whoever votes needs time to think about the size, not an answer off the top of their head.

Have the room link ready before you start, too: whoever joins late doesn't have to wait for a new round — they simply join the next story without breaking the pace.

The Pointly room covers the voting part: pick a nickname, share the 4-character code in your team channel and start once everyone is in.

Who votes (and who doesn't)

Whoever builds the story votes. Developers and the people who will do the work vote; product, design and the facilitator join the conversation but stay out of the vote.

That keeps the estimate from being shaped by people who won't feel the effort day to day — and keeps the number from turning into a delivery promise. The facilitator has another job: make sure everyone understands the story before voting and that the conversation doesn't become a defense of positions.

On small teams, roles overlap naturally. The agreement matters more than the rule: if the same person builds and facilitates, take turns running the round so everyone can vote.

A simple rule of thumb: if the person will put their hands on what gets delivered — code, design, data — they vote. If their part is context or decision, they join the conversation.

The round in 7 steps

The order below works for any story. Practice changes how long each step takes, not the sequence.

1. Describe the story. Whoever knows the item reads the context and acceptance criteria out loud. If there's a mock, screenshot or link, show it to the team.
2. Answer questions before the vote. Understanding questions happen now, not after the reveal. If the answer doesn't exist yet, consider estimating with the break card.
3. Vote in secret. Everyone picks a card without seeing anyone else's — simultaneous voting is what prevents anchoring on the first opinion.
4. Reveal together. All cards turn at the same time. The median, the mean and the range show up on the table, along with the vote distribution.
5. Lowest and highest explain. The lowest and the highest votes speak first; the rest of the team listens before responding.
6. Talk about the difference. The goal is to understand what each vote saw — not to convince anyone. Often it's the story that changes, not the person.
7. Close it or vote again. The team closes on the agreed number or runs a second round with what it learned. Extra rounds are cheap; rework isn't.

How long it takes

With practice, a small story takes 2 to 5 minutes — discussion included. Complex items can reach 10. If the conversation goes past that, the problem isn't the estimate: context is missing, and the item goes back to refinement.

In a two-hour planning session, teams usually estimate 15 to 30 items at that pace, depending on story size and how far the conversation spreads.

When the votes disagree

Disagreement isn't an error — it's information. The size of the spread tells you how much conversation the story needs before the next round.

The median is the natural reference to close the round. The mean helps read the group, but it doesn't decide on its own: the final number belongs to the team, not the spreadsheet.

A second round is not a failure. When the spread shrinks, it means the conversation worked — even if the team hasn't closed yet.

After the reveal

The agreed number goes to the backlog with the story. When the item is done, compare the real effort with the estimate: that's how the team's reference story becomes more honest over time.

If the story changed scope mid-sprint, re-estimate — no drama. Story points describe what was known at vote time, not a contract.

Over time, the set of estimated numbers becomes the team's velocity — and it's velocity, not the estimate of a single item, that helps plan the next sprint.

Common mistakes

• Estimating in hours. Points measure relative effort; converting them to days breaks the scale on the first sprint.
• Letting the product owner vote. It turns the estimate into a delivery promise and skews the number.
• Treating the mean as the decision. The number is where the conversation starts, not where it ends.
• Skipping the talk when everyone agrees. Unanimity also deserves a confirmation question: did everyone consider the same thing?
• Estimating on autopilot. A ritual without discussion becomes time tracking by another name.
• Estimating without the whole team. Someone who wasn't in the conversation tends to disagree with the number later. If a key person was missing, re-estimate with them there.

Frequently asked questions