Planning Poker
Estimate user stories with Fibonacci cards. Pick your card, then reveal all at once to avoid anchoring bias.
Files processed in your browser — never uploaded to our serversPick your card
What is Planning Poker?
Planning poker (Scrum poker) is a consensus-based estimation technique where team members simultaneously reveal their story point estimates to avoid anchoring bias. If one person reveals their estimate first, others naturally anchor on that number — simultaneous reveal prevents this and surfaces genuine disagreement. The standard card values follow a Fibonacci-inspired sequence: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, and infinity. Fibonacci works better than a linear scale because the growing gaps between large numbers reflect genuine estimation uncertainty — a 40-point story is not just twice as complex as a 20-point story, it carries far more unknowns. Story points are a relative unit of effort, not a time unit: a 5-point story is simply understood to be more effort than a 3-point story by however the team defines their scale.
How to use
- Add team members who will participate in the estimation session.
- Present a user story or task description so all participants understand what is being estimated.
- Each team member privately selects their story point estimate from the Fibonacci card deck.
- Reveal all estimates simultaneously — this prevents anchoring bias from early influencers.
- If estimates are close, accept the consensus or the average and record the final point value.
- If estimates diverge widely (e.g. one person picks 3 and another picks 13), ask the highest and lowest estimators to explain their reasoning, then re-vote.
Why it matters
Planning poker surfaces estimation disagreement that would otherwise be hidden. When one developer estimates 3 points and another estimates 13 for the same story, they are operating on different assumptions about scope, technical approach, or risk. That conversation — triggered by the estimate gap — prevents the misalignment that causes sprint failures mid-delivery. Teams that skip estimation or allow one person to dictate estimates routinely discover, mid-sprint, that a story was far larger than assumed. Consensus estimation builds shared understanding of the work before it begins.
Pro tip
If a team cannot reach consensus after 2 rounds of voting, the user story is too large or too unclear to estimate reliably. Split it into smaller stories or spike it — timebox an investigation task to resolve the uncertainty before committing to a point value. A story the team cannot agree on is a story that will fail in the sprint.