Planning Poker

---

Origins

Planning Poker was developed by James Grenning in 2002¹ and popularized by Mike Cohn in Agile Estimating and Planning². Grenning was tired of estimation meetings that produced lower-quality answers than the team's members would have produced alone. The dominant voice anchored everyone else; quieter members deferred; the resulting estimates were thin compromises that satisfied nobody.

The technique borrowed from the Wideband Delphi method — expert estimation with iterative consensus — and added a deck of cards. The cards do two jobs: they constrain the estimate to a Fibonacci-ish scale, and they enable simultaneous reveal so nobody anchors.

The Mechanics

Each estimator gets a deck of cards. The scale is typically a modified Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, plus a "?" card for "I don't know" and a coffee-cup card for "I need a break."

For each item to estimate:

1. Product owner reads the item: brief description, business context, acceptance criteria.
2. Team asks clarifying questions: discussion until everyone understands what's being estimated.
3. Each estimator picks a card silently: holds it face-down. No talking, no anchoring.
4. Simultaneous reveal: everyone flips their card at once.
5. Discuss outliers: the highest and lowest cards explain their reasoning. Often this surfaces information others didn't have.
6. Re-vote: same item, second silent vote. Usually converges; sometimes another round is needed.
7. Move on when consensus emerges: typically a final agreed number, occasionally a "we need to split this story" decision.

Why the Format Works

Planning Poker's effectiveness comes from features most estimation meetings lack:

• Simultaneous reveal prevents anchoring: no one sees others' estimates before committing to their own.
• Fibonacci scale enforces honesty about precision: the gap between 8 and 13 is wider than between 2 and 3, reflecting actual uncertainty growth with size.
• The discussion is forced by disagreement: outliers explain why. The discussion produces shared understanding, not just shared numbers.
• Quieter voices have equal weight: the developer who knows the system but doesn't speak up first still gets to share their estimate.
• The estimate is the team's, not one person's: ownership of the number is shared, which reduces the "you committed me to this" problem.

The Cards Themselves

The Fibonacci scale (1, 2, 3, 5, 8, 13, 20, 40, 100) has natural properties:

• Small differences matter at small sizes (you can distinguish a 2 from a 3).
• Small differences blur at large sizes (an 80 and a 90 don't really differ in estimation precision).
• The scale forces estimators to round honestly to the nearest available option.
• Anything above 13 is a signal the item should probably be split.

Some teams use T-shirt sizes (XS, S, M, L, XL) instead. The principle is the same — a coarse scale that prevents false precision.

Common Pitfalls

• Talking before voting: people share their thoughts before flipping cards. The first speaker anchors everyone; the format's main protection is gone.
• Vote-and-move-on: skipping the discussion of outliers. The estimate gets recorded but the team's shared understanding doesn't.
• Endless rounds: re-voting until consensus emerges artificially. If two rounds don't converge, the right move is usually to split the story or accept the divergence and pick the higher estimate.
• Treating points as hours: "this is 5, so it's 5 days." Story points are relative; their conversion to time happens via velocity over many sprints, not per-item.
• Sandbagging: estimators learn that bigger numbers mean less pressure and start voting higher than they believe. Defeats the format's honesty.
• Estimating without enough information: planning poker on stories that aren't refined enough produces meaningless numbers. Either refine first or expect the discussion to do refinement work.

Coaching Tips

Enforce Silent Voting

One person's first comment anchors the whole vote. Insist on flipping cards before discussion.

Discuss Outliers Always

The high and low cards have information the rest of the team needs. Skipping the discussion wastes the format's value.

Stop After Two Rounds

If two rounds haven't converged, force a decision: split the story or take the higher estimate. Endless voting is theater.

Refine Before Estimating

Planning Poker on under-refined stories produces noise. Run example mapping or a refinement pass first.

Watch for Sandbagging

If estimates keep growing, the team is protecting itself from pressure. Address the pressure, not the estimates.

Split Big Items

Items above 13 are usually too big to estimate accurately. Split, then estimate the parts.

Summary

Planning Poker is one of the more durable contributions of XP-era estimation practice. It produces better estimates than open discussion not because the math is better, but because the social mechanics protect the conversation from the failure modes that ruin most estimation meetings. The technique works for small teams with good story refinement; it doesn't scale well to large groups, and it depends on the team taking the discussion of outliers seriously.

The deeper value isn't the number on the card. It's the conversation the outliers force — the moment a developer says "I voted 13 because I think we need to migrate the database schema" and the rest of the team realizes they hadn't considered that. The estimate is a side effect; the shared understanding is the product.

Back to Agile Delivery