If you've ever sat through a sprint planning meeting where the team argued for 45 minutes about whether a story was a 5 or an 8, you already know why planning poker exists.
Planning poker — also called Scrum poker or estimation poker — is a consensus-based agile estimation technique that helps teams size user stories quickly, accurately, and without anchoring bias. It's one of the most widely used practices in Scrum, and for good reason.
How Planning Poker Works
The process is straightforward:
- The Scrum Master presents a user story to the team.
- Each team member privately selects a card representing their effort estimate.
- Everyone reveals their cards simultaneously.
- If estimates align closely, the group agrees and moves on.
- If estimates diverge, the highest and lowest estimators explain their reasoning — then the team re-votes.
The simultaneous reveal is the key mechanic. It prevents anchoring — the cognitive bias where the first number spoken influences everyone else's estimate.
What Numbers Are Used?
Most teams use the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. Some teams use a modified version: 1, 2, 3, 5, 8, 13, 20, 40, 100.
The gaps between higher numbers are intentional. When a story might be a 20 or a 40, that uncertainty is meaningful — it tells you the story is too large or too poorly understood to estimate confidently. Break it down first.
Special cards often include:
- ☕ (coffee) — I need a break
- ? (question mark) — I don't understand this story
- ∞ (infinity) — This story is way too large
Why Story Points, Not Hours?
Story points measure relative effort, not time. This is a critical distinction.
When you estimate in hours, team members anchor to their own speed. A senior developer and a junior developer will estimate the same task very differently in hours, but similarly in relative effort. Story points normalize this.
They also account for complexity and uncertainty — not just raw effort. A story that's technically simple but involves touching a legacy system nobody understands should score higher than a complex but well-understood feature.
Common Mistakes Teams Make
1. Letting the SM or tech lead speak first
This anchors the entire team. Always reveal cards simultaneously, never sequentially.
2. Estimating tasks instead of stories
Plan at the user story level during poker. Task breakdown happens after estimation, not during it.
3. Spending too long on outliers
Two rounds of discussion is usually enough. If the team still can't converge, the story needs to be broken down or better defined — not debated further.
4. Using planning poker for every item
Bugs, minor improvements, and well-understood tasks don't always need full poker sessions. Use your judgment.
Running Planning Poker in SprintFlow
SprintFlow has planning poker built in — no plugins, no third-party tools, no extra subscriptions. Here's how a session works:
- The SM triggers a voting session on any user story.
- Team members receive a notification and join the voting room.
- Everyone votes privately using Fibonacci cards.
- The SM reveals all votes simultaneously.
- Story points are assigned with one click.
The entire flow happens inside your sprint board. No tab switching, no separate tool, no manual SP entry.
💡 Pro tip: Before the planning poker session, make sure every story has a clear title and at least a one-line description. Ambiguous stories are the #1 cause of estimation disagreement.
How Many Stories Should You Estimate Per Session?
A good rule of thumb: estimate enough stories to fill 1.5x your sprint capacity. If your team typically completes 40 story points per sprint, aim to have 60 points estimated and ready in the backlog.
This gives you a buffer if some stories get deprioritized or new urgent work comes in mid-sprint.
The Bottom Line
Planning poker isn't just an estimation tool — it's a conversation facilitator. The real value isn't the number on the card. It's the discussion that happens when the cards are revealed and estimates differ.
That conversation surfaces hidden complexity, knowledge gaps, and technical risk before work begins — when it's cheapest to address.
Run it well, and your sprint planning meetings get shorter, your estimates get more accurate, and your team gets better at sizing work over time.