Guide
The complete guide to planning poker
A consensus-based estimation technique that has become the default in agile teams for sizing backlog items. This guide covers what it is, where it came from, why it works, and how to run a session that actually converges.
What is planning poker?
Planning poker is a consensus-based estimation technique. Each team member privately picks a card representing their effort estimate for a backlog item. Everyone reveals at the same time. If estimates differ widely, the gap is discussed and the team re-votes.
The mechanic does one specific thing: it eliminates anchoring on the loudest voice. In an ad-hoc estimation discussion, the first number stated — usually by the most senior person in the room — pulls every subsequent estimate toward it. Simultaneous reveal makes that anchoring impossible.
It is the most widely used estimation technique in Scrum and Extreme Programming.
For deeper dives, see:
Story points explained · The Fibonacci scale in agile estimation · Planning poker for distributed teams · Planning poker vs. scrum poker
Where it came from
James Grenning invented planning poker in 2002. He was watching a team estimate a backlog one item at a time, with developers voicing opinions sequentially. Hours in, they had covered a fraction of the work. Grenning grabbed index cards, wrote numbers on them, and turned the session into simultaneous reveals. He later wrote the original article describing the technique.
Mike Cohn popularised it in 2005 through his book Agile Estimating and Planning, which is still the canonical reference for sizing backlogs in Scrum teams.
Planning poker is a direct simplification of Wideband Delphi, an estimation method described by Barry Boehm in his 1981 book Software Engineering Economics. Wideband Delphi runs the same iterative-convergence loop but uses written submissions and a moderator — planning poker collapses that into a card-based round.
Why it works: anchoring and group convergence
Two effects make planning poker more accurate than ad-hoc discussion:
Anchoring elimination
Cognitive psychologists call it the anchoring bias: people's numerical estimates get pulled toward whatever number they hear first. The effect is well-documented since Tversky and Kahneman's 1974 Science paper Judgment under Uncertainty. Simultaneous reveal removes the first-number effect by removing the first number. Every estimate is independent.
Forced articulation of disagreement
When two team members vote 3 and 13 on the same story, the gap is concrete and impossible to gloss over. The natural follow-up — "what is each of you thinking? " — surfaces an unspoken assumption, missing context, or a definition mismatch that would otherwise have shipped along with the wrong estimate. The estimate improves because the input improves.
The underlying method (Wideband Delphi) has been studied formally since the 1970s. Iterated group estimates converge on values significantly more accurate than any individual expert's first guess — a result that has held across multiple replications.
How a session runs
In Ace-The-Backlog, three steps:
- Paste the backlog. Drop in tickets one per line. JIRA keys, ticket descriptions, or short summaries all work. Up to 200 items per session.
- Configure roles and scales. Up to five voting roles per session, each with its own scale. Common combinations: Dev (Fibonacci) + QA (Fibonacci) + Design (T-shirt) on the same ticket — captures the full effort picture, not just engineering.
- Share the room link. Everyone joins live in-browser, no account needed. Voting is per-role per-ticket: Dev votes first, reveal, discuss, lock in. Then QA on the same ticket. Then Design. Move to the next ticket.
A session of 10 to 20 tickets typically takes 30 to 60 minutes depending on how much discussion each disagreement surfaces. Rooms auto-delete after 24 hours.
Estimation scales
Most teams default to Fibonacci story points (1, 2, 3, 5, 8, 13, 21). The widening gaps are deliberate — they mirror a real property of human estimation: the larger the work, the less precise any single number can be. A "13" carries an implicit "this is rough; we don't have enough resolution to distinguish from a 21".
Other scales work in specific contexts:
- Hours (1h to 40h) — for tasks under one to two days where the team has shared norms ("a CRUD endpoint with tests is 4h"). Concrete enough to plan a day around, fuzzy enough to absorb small surprises.
- Days (0.5d to 13d) — for milestone-level planning, not individual stories. Useful for roadmaps.
- T-shirt sizes (XS to XXL) — for early-stage rough sizing before stories are broken down. Less commitment than a number; helps prioritise without claiming precision.
In this tool, each voting role picks its own scale per session — Dev in Fibonacci, Design in T-shirt sizes, on the same ticket. See the Fibonacci scale guide for why the widening gaps matter and story points explained for what you are actually estimating.
Common pitfalls
Anchoring through "what did everyone vote last time?"
Showing the previous round's votes during re-vote partly defeats the point. Keep re-votes anonymous and only surface them at the next reveal.
Estimating in a vacuum
A team that has never delivered a story together has no shared sense of what a "5" means. The first three to five sprints, calibrate by anchoring against a known reference story ("we delivered this in three days; that is our 5").
Letting one person dominate the post-reveal discussion
Planning poker is good at surfacing the gap, less good at resolving it. A facilitator who explicitly invites the outlier voters — not the most senior person — to speak first is the practical fix.
Estimating 13+ stories
Anything that lands consistently at 13 or higher is too big to estimate accurately and probably too big to deliver in a sprint. Split it.
FAQ
- How many people should be in a planning poker session?
- Three to seven voters is the sweet spot. Below three you lose the group-convergence effect; above seven, sessions get long and outlier discussions fragment. Spectators and stakeholders can join without voting.
- Can I use planning poker outside of Scrum?
- Yes. Planning poker is a general consensus-estimation technique. Scrum is the most common context, but Kanban teams, Extreme Programming teams, and product-management groups all use it.
- What if everyone votes the same on the first round?
- You are done. Lock the value, move to the next ticket. Convergence on the first round is the goal, not a failure mode.
- How long should a planning poker session take?
- Plan two to four minutes per ticket for a well-refined backlog. A 15-item session typically lands at 30 to 60 minutes. Longer means the backlog is not ready — vague stories or missing acceptance criteria — and the fix is in the input, not the session.
- Should the product owner vote?
- Generally no. The product owner brings context and answers questions but does not vote on effort. The voters are the people who will do the work.
Ready to run a session?
Open the tool and paste your backlog. No account, no sign-up. Sessions auto-delete after 24 hours.
Start a planning poker session