Planning Poker

Planning Poker (or Scrum Poker) is an agile estimation technique where all team members simultaneously reveal their estimate for a story, preventing anchoring bias from early influencers.

Fibonacci numbers (1, 2, 3, 5, 8, 13…) reflect the natural uncertainty in estimation — the larger a task, the less precise the estimate. The growing gaps force the team to acknowledge uncertainty.

The ? card means 'I don't have enough information to estimate.' It signals that the story needs clarification before the team can commit to a point value.

∞ (infinity) means the story is too large or too vague to estimate as-is. It should be broken down into smaller stories before the next sprint.

This version is single-player — useful for a facilitator to collect votes verbally or in a shared screen session. Each team member picks their card, the facilitator records the consensus.

The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21…) represents story points — a relative measure of effort, complexity, and uncertainty rather than hours. Larger numbers have larger gaps to reflect the inherent imprecision of estimating bigger pieces of work.

All team members select their estimate privately and reveal their cards simultaneously. This prevents the first person to speak from anchoring everyone else's judgment. When estimates differ widely, it opens a productive discussion rather than a groupthink consensus.

Planning poker works best with 3 to 8 participants — typically the development team plus the scrum master. Larger groups can participate but the discussion after revealing divergent estimates becomes harder to manage efficiently.

Wide divergence is valuable — it signals a difference in understanding or approach. Ask the highest and lowest estimators to explain their reasoning. Often this surfaces a missing requirement, a technical concern, or a simpler implementation that neither side had considered.

No — any team that needs to estimate relative effort for tasks can use planning poker. Content teams, marketing teams, and operations groups all use it to size projects and prioritize backlogs, even without a formal software development context.