Votenir
Planning poker is easy to learn and surprisingly easy to do badly. Most teams pick it up in one meeting, then spend the next year in estimation sessions that run long, end in "let's just call it a 5", and produce numbers nobody trusts.
These planning poker best practices come from what consistently separates fast, useful sessions from slow, painful ones. None of them need special tools, but a good tool makes most of them automatic.
1. Agree on a reference story before you start
Story points are relative, so they need an anchor. Pick one completed story the whole team remembers, such as "the CSV export bug", and agree its size (often a 2 or 3). Every new estimate becomes a comparison: bigger or smaller than the export bug?
Without a reference, each person is silently using their own scale, and the reveal turns into an argument about what a point means. Story points explained goes deeper on this.
2. Refine before you estimate
Planning poker is not the place to discover what a story is. If the team is hearing about a story for the first time in the session, half the time goes on questions that belong in backlog refinement.
A simple rule: a story is ready to estimate when it has acceptance criteria and someone on the team can explain it in under a minute.
3. Keep votes hidden until everyone has chosen
The entire value of planning poker comes from independent estimates. The moment someone says "I'm thinking 8" before the reveal, everyone else anchors to it.
Use a tool where cards stay face-down until the reveal and the table shows who has voted but not what. In Votenir the values never leave the server until the owner reveals, so nobody can peek.
4. Reveal all cards at once
Simultaneous reveal is what makes planning poker different from going round the table. If cards are revealed one by one, or people say their numbers out loud in turn, the later voters have already heard the earlier ones.
5. Discuss the outliers, not the average
The average is the least interesting thing on the table. The useful information is in the spread: why did one person play a 2 and another a 13?
Ask the highest and lowest voters to explain, in that order, in one or two sentences each. Usually one of them has spotted a risk or a shortcut the others missed. Our guide to handling disagreement has a full playbook.
6. Re-vote at most once
After the outliers explain, vote again. If the team converges, you're done. If it doesn't, don't loop. Take the higher estimate, split the story, or mark it for a spike. A third and fourth round almost never produces new information; it just wears people down.
7. Timebox every story
Set a limit of around five minutes per story, including discussion. When time runs out, apply rule 6. A visible timer helps; so does a facilitator who's willing to say "we've learned what we can, let's move on".
As a rough guide, a healthy session covers 8–12 stories an hour.
8. Respect the ? and ☕ cards
A ? means "I don't have enough information". It's useful data, not a non-answer. If two or more people play it, stop and clarify the story.
A ☕ means "I need a break". After 45–60 minutes of estimating, quality drops fast. Take the break. More on both in The ? and coffee cards.
9. Let the people doing the work vote
Developers, testers and anyone else who'll build the story should vote. Product owners and Scrum Masters usually shouldn't. They can answer questions, but their estimates tend to anchor the team, especially when they're more senior.
If stakeholders join for context, give them a clear role: they explain the "what" and "why"; the team sizes the "how much".
10. Keep a record and look back at it
Estimates are only useful if they're roughly right, and you only find out by comparing them with what happened. Save each round's votes and final number, then review a few at your next retrospective:
- Which stories were badly under-estimated? What did we miss?
- Do we consistently disagree on a certain type of work (front-end, migrations, integrations)?
- Are we splitting enough large stories?
Votenir saves every revealed round automatically, with each person's vote, so this review takes minutes. Because retrospectives live in the same workspace, the lessons go straight into your retro board.
Quick checklist
| Before the session | During each story | After the session |
|---|---|---|
| Stories refined with acceptance criteria | Read it out, then silent voting | Review saved rounds |
| Reference story agreed | Reveal together | Split or spike the stories marked |
| Deck chosen (guide) | Outliers explain, re-vote once | Bring patterns to the retro |
| Voters invited (the people doing the work) | 5-minute timebox |
Frequently asked questions
How long should a planning poker session last?
Aim for 45–60 minutes at most. Beyond that, estimates get worse. If you have more stories, run a second session another day.
Should the Product Owner vote in planning poker?
Generally no. The Product Owner explains the story and answers questions; the people doing the work estimate it.
What do you do if the team can't agree?
Re-vote once after the outliers explain. If there's still no agreement, take the higher estimate, split the story, or schedule a spike.
How many stories should you estimate per hour?
Around 8–12 well-refined stories is a healthy pace. Far fewer usually means stories aren't refined enough before the session.