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.