What is Planning Poker?

Planning poker (also called scrum poker) is a consensus-based agile estimation technique used by software teams during sprint planning. Team members each hold a hand of cards — numbered using a Fibonacci-like sequence — and simultaneously reveal their estimate for a user story or task. Because everyone reveals at the same time, the method prevents anchoring bias, where one person's opinion unduly influences the rest of the team. The name comes from the simultaneous card reveal, which resembles a poker showdown. Unlike poker, the goal is agreement: when estimates differ, the team discusses why and replays until they reach consensus.

• Avoids anchoring — no one's estimate is revealed first, so everyone thinks independently. • Surfaces hidden complexity — gaps between high and low estimates reveal assumptions the team hasn't discussed. • Builds shared understanding — the discussion that follows a split vote is often more valuable than the number itself. • Keeps planning fast — time-boxed rounds prevent endless debate. • Works remotely — tools like Scrum Points let distributed teams vote simultaneously from any device.

1. The product owner or scrum master reads out a user story or task. 2. Each team member privately selects a card representing their effort estimate — typically in story points. 3. Everyone reveals their card at the same time. If all estimates match (or are close), the team accepts the estimate and moves on. 4. If estimates vary, the highest and lowest estimators briefly explain their reasoning. The team discusses, then votes again. 5. Rounds repeat until the team reaches consensus, usually within two or three plays.

Fibonacci (1, 2, 3, 5, 8, 13, 21…) The most popular scale for planning poker. The gaps between numbers grow as complexity increases, which mirrors how uncertainty compounds in larger tasks. Trying to estimate a 13-point story to the precision of a 1-point story is a false certainty — the Fibonacci sequence reflects that. T-shirt sizes (XS, S, M, L, XL) A relative scale useful for early-stage roadmap estimation when exact point values feel premature. Great for teams new to agile estimation or when estimating epics rather than individual stories. Powers of 2 (1, 2, 4, 8, 16…) Similar to Fibonacci but with larger gaps. Useful for teams that want to force a binary choice between "roughly the same" and "roughly double the work". Custom scales Scrum Points lets you define your own card values — useful for teams that have developed their own estimation conventions over time.

Story points measure relative effort and complexity, not raw time. A 5-point story is roughly twice the effort of a 3-point story — but one developer might complete it in 2 hours while another takes 4. Points abstract away individual productivity differences and stay meaningful as the team's velocity naturally accounts for its own pace. Estimating in hours tends to be optimistic and doesn't account for unknowns. Story points encourage teams to think about risk and complexity, not just calendar time.

• Groom stories before the session — each story should have a clear description, acceptance criteria, and any known dependencies resolved before the team estimates it. Estimating vague stories wastes everyone's time. • Keep stories small — anything above 8 points is usually a candidate for splitting. • Use a reference story — agree on what a "3" looks like before the session starts. • Time-box discussion — aim for 5–10 minutes per story; if the team still can't agree, the story probably needs splitting. • Include the whole team — QA, design, and ops surface edge cases developers miss. • Don't average — consensus through discussion produces better estimates than the mean of a disagreeing team. • Track velocity — compare estimated points to completed points each sprint to calibrate future estimates.

A wide spread is the most valuable thing that happens in a planning session. It almost never means someone estimated badly — it means two people are picturing different work. One has remembered the legacy integration, the other has not. The standard move is to ask the highest and the lowest estimator to explain their reasoning, in that order, and keep it brief. Then re-vote. Most disagreements collapse in a single round once the hidden assumption is said out loud. If a second round does not converge, stop estimating. A persistent spread usually means the story is not ready — there is a genuine unknown that discussion cannot resolve. Send it back for refinement, or timebox a spike and estimate the real work afterwards. Do not average the votes: the average is a number nobody believes, and it hides the risk that caused the disagreement in the first place.

A healthy session spends about two minutes per story. If you are regularly spending ten, the bottleneck is refinement rather than estimation — the team is discovering requirements during the session instead of sizing work it already understands. Practical guardrails that keep sessions short: • Timebox each story. A running timer is remarkably effective at ending circular debate. • Cap the session at an hour. Estimation quality falls off sharply after that. • Do not re-estimate stories that only changed cosmetically. • If two adjacent values are in contention, take the higher one and move on — the difference will not survive contact with reality. • Park anything that needs a decision from someone not in the room, rather than guessing on their behalf.

Planning poker was designed around a physical deck of cards, and the thing that made it work was simultaneity — everyone committing at once, so nobody anchors on the loudest or most senior voice. Remote teams lose that by default: in a video call, whoever speaks first sets the number. A shared room restores it. Votes stay hidden until the host reveals, so the commitment is genuinely simultaneous even when people are in five timezones. Beyond that, a few habits help distributed sessions specifically: put the story text and acceptance criteria somewhere everyone can read without switching windows, let people vote before anyone speaks, and give quieter participants an explicit turn during discussion rather than relying on them to interrupt. For teams that genuinely cannot meet at the same time, asynchronous estimation is a reasonable fallback — participants vote over a working day and the host reveals when everyone is in — but you lose the discussion, which is most of the value. Treat it as a way to flag disagreement, then meet briefly about the stories that actually diverged.

Everyone who will do the work should estimate: developers, testers, and anyone else whose effort the story depends on. People who will not do the work — stakeholders, managers, the product owner — should be present to answer questions but should not vote. Their estimate carries implicit authority and quietly anchors the room. Spectator mode exists for exactly this. Observers see the discussion and the results but are excluded from the vote count, so a watching director cannot skew the number simply by having an opinion. Keep the voting group small — roughly four to eight people. Below that you lose the diversity of perspective that makes the spread informative; above it, discussion becomes unmanageable and sessions run long.