Planning Poker

Estimate user stories with Fibonacci cards. Pick your card, then reveal all at once to avoid anchoring bias.

0/4 Vote recorded

Round Participants4

Alice (Dev)
?
Pending
Bob (Dev)
?
Pending
Charlie (QA)
?
Pending
You
?
Pending

Select a participant and pick a card: Alice (Dev)

How to Use

01

Add team members who will participate in the estimation session.

02

Present a user story or task description so all participants understand what is being estimated.

03

Each team member privately selects their story point estimate from the Fibonacci card deck.

04

Reveal all estimates simultaneously - this prevents anchoring bias from early influencers.

05

If estimates are close, accept the consensus or the average and record the final point value.

06

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.

What Is This Tool?

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.

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.

Frequently Asked Questions