What is Planning Poker?
Planning Poker (also called Scrum Poker) is an agile estimation technique where every team member votes privately on how complex a task is, then everyone reveals their cards at the same time. The simultaneous reveal is the key mechanic: it prevents any one person from anchoring the group before everyone has formed their own opinion.
The result is a quick, structured way to surface disagreement — and disagreement is valuable. When a developer votes 13 and a QA engineer votes 3, that gap usually means someone is aware of a risk, a dependency, or a constraint that the rest of the team hasn't considered yet.
Story points, not hours
Most teams use story points rather than hours. Hours imply a precise schedule; story points capture relative complexity and uncertainty. A "5" just means "this is roughly twice as involved as a 2 and about half as involved as an 8" — no calendar commitment attached.
The most common scale is the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21…). The widening gaps are intentional: they reflect the fact that the bigger a piece of work, the harder it is to estimate with precision. Teams that prefer a simpler vocabulary often use T-shirt sizes (XS, S, M, L, XL) instead. Based on aggregated ScrumJam session data, over 90% of teams use Fibonacci. See the Fibonacci vs T-shirt sizing comparison for guidance on which scale suits your team, or browse all available estimation decks.
The cards in the deck
Beyond the numbered cards, most decks include a few special cards worth knowing:
- ? (unsure) — "I don't have enough information to estimate this story." This card is useful for signalling that a story needs more refinement before the team can commit to any number.
- ☕ (break) — The session has run long enough that estimates are degrading. Time to pause before continuing.
- ∞ (too large) — The story is so big it needs to be split before estimation makes sense.
If more than two people play the ? card on the same story, that's a clear signal to defer the story until the Product Owner can add acceptance criteria.
How a session runs: step by step
Based on real ScrumJam session data, the median session lasts about 33 minutes and teams flip cards 2–3 times per session on average. Most sessions stay well under an hour when stories are ready to estimate.
- Open the room and share the link. With an online tool like ScrumJam, send the room link in Slack before the meeting. Everyone joins before the first story.
- Product Owner reads the story aloud. Then fields questions — no estimates yet. This clarification phase is where most misunderstandings surface.
- Each person picks a card privately. Everyone selects their estimate without seeing what others have chosen.
- Simultaneous reveal. The facilitator counts down (3, 2, 1) and everyone flips their card at the same time. Nobody adjusts based on what they think others will vote.
- Discuss the spread. If estimates are close, the team often converges quickly. If there is a wide spread — say a 2 and a 13 on the same story — the outliers explain their reasoning first. The goal is shared understanding, not splitting the difference.
- Re-vote if needed. One more round usually converges. If the team still cannot agree, either split the story or accept the higher estimate and flag the uncertainty.
- Record the result immediately. Write the agreed point value in Jira, Linear, or your tracker before moving on. "We'll update it later" reliably doesn't happen.
Where planning poker fits in the sprint cycle
Planning poker belongs in backlog refinement, not in the sprint planning meeting. By sprint planning, stories should already be estimated so the team can focus on selecting a sprint goal rather than debating complexity under time pressure.
A useful rule of thumb: estimate stories when they are about two sprints away from being worked. Any earlier and stories are too likely to change; any later and you are estimating in the sprint planning meeting itself.
For a deeper look at where poker fits across the full sprint cycle, see the sprint planning poker guide.
Tips for remote and distributed teams
Remote refinement is now the default for most teams. A few habits make it work well:
- Paste the story link in the chat before reading it aloud. People read faster than you speak; having the text visible cuts re-reads and "can you repeat that."
- Cameras on for discussion, muted during silent estimation. Facial expressions carry a lot when someone explains why they voted 13. Background noise during the thinking phase disrupts focus.
- Drop the agreed estimate in the story's comments. A one-sentence rationale helps async teammates who missed the call follow the reasoning.
- Timebox each story. 5–8 minutes per story covers most cases. If a story sparks a 10-minute architectural debate, defer it rather than burning through the session.
Why planning poker works
A few specific reasons the technique produces better estimates than a group discussion where someone calls out a number first:
- Simultaneous reveal prevents anchoring. Nobody sees a "5" and unconsciously adjusts their "8" to match before the count.
- Participation is equal by design. Junior developers and senior architects vote at the same time. No one can dominate the estimate by speaking first.
- Disagreement is surfaced, not suppressed. A wide spread is a signal that the team has different mental models of the work — which is exactly what you want to discover in refinement, not mid-sprint.
- Shared vocabulary builds over time. A team that has estimated together for a few sprints develops an implicit shared understanding of what a "3" feels like versus a "5." New members calibrate quickly.
Common pitfalls
- Estimating unready stories. If a story has no acceptance criteria, play the ? card and send it back to the Product Owner. Estimating on incomplete information produces noise, not signal.
- Averaging outliers instead of discussing them. A 2 and a 13 averaged to 7 resolves the conflict on paper while hiding the real disagreement underneath.
- Marathon sessions. Estimate quality degrades quickly in the second hour. The median well-run session is around 33 minutes — if yours regularly run longer, split into two sessions across the week rather than one long block. See the benchmarks page for how your sessions compare to the average.
- Tracking velocity in hours instead of points. This collapses effort, complexity, and uncertainty into a single number that implies false precision.
Connecting estimates to sprint velocity
Once stories are estimated, sprint planning becomes a capacity exercise: the team pulls in stories until the total points match their recent average velocity. Use a rolling three-sprint average rather than a single sprint peak — velocity varies, and over-committing based on a good week sets the team up for a bad one.
If your team is brand new, start conservatively. The first sprint's estimates don't need to be accurate; they need to be consistent relative to each other. Accuracy follows as the team calibrates over several sprints.
Ready to run your first session?
Open a free room, paste the link in Slack, and run through the steps above. If your team uses Jira, you can import your backlog directly into the session — see the Jira integration page for setup. For a broader reference on running sessions well, the planning poker handbook covers everything from deck choice to velocity calibration. For more advanced technique, the agile scrum estimation practices guide covers what to do when estimates consistently drift from actuals.
For further reading on Agile and Scrum methodologies, the Scrum Alliance Articles are a good starting point.
