Planning poker
Planning Poker is a consensus-based agile estimation technique where development team members simultaneously reveal numerical cards representing their effort estimates for user stories or tasks. The simultaneous reveal prevents anchoring bias - early opinions influencing later ones - and the ensuing discussion surfaces assumptions and risks that improve both the estimate and the team's shared understanding.
Why it matters
Estimation is notoriously difficult, and traditional approaches make it worse. When a senior developer estimates first, others anchor to that number. When estimates are discussed openly, social dynamics distort honest assessment. When one person estimates for the team, valuable perspectives go unheard.
Planning Poker addresses these problems. Simultaneous reveals ensure independent thinking. Required discussion when estimates diverge surfaces hidden complexity. The collaborative format builds shared understanding and ownership.
How planning poker works
The basic process is straightforward.
A moderator presents a user story - reading it aloud and answering clarifying questions. Everyone needs to understand what's being estimated before estimating.
Team members privately select cards representing their estimate. Typical sequences include Fibonacci (1, 2, 3, 5, 8, 13, 21) or modified versions that include uncertainty markers. Each person chooses without seeing others' selections.
Everyone reveals simultaneously. On a count of three or a signal from the moderator, all cards flip. The simultaneous reveal prevents early votes from influencing later ones.
The team discusses divergence. If estimates vary significantly, the highest and lowest estimators explain their reasoning. This discussion often reveals that people were making different assumptions or saw different risks.
The team re-estimates if needed. After discussion, another round of simultaneous voting may occur. Convergence usually happens within two or three rounds.
The team records the final estimate. Once consensus is reached (or close enough), the estimate is captured for sprint planning.
The card values
Most Planning Poker decks use a modified Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 21, and sometimes larger numbers for very big items.
The non-linear spacing is intentional. The difference between 1 and 2 is meaningful; the difference between 21 and 22 is not. Larger numbers are inherently less precise, and the card values reflect this reality.
Special cards often include:
Why simultaneous reveal matters
The key insight of Planning Poker is that estimation quality improves when each person thinks independently before hearing others' opinions.
Anchoring bias is powerful. If a respected senior developer says "5," others unconsciously adjust toward that number even if their independent assessment would have been different. Simultaneous reveal eliminates this entirely.
Social pressure also distorts estimates. People avoid disagreeing with high-status team members or don't want to be the outlier. When everyone commits before seeing others' cards, these pressures can't operate.
Diverse perspectives improve estimates. Different team members see different risks and complexities. Independent voting ensures all perspectives are captured, not just the loudest or first ones.
The value of divergence
When estimates diverge - one person plays a 3, another plays a 13 - something interesting has happened. The estimators are seeing the work differently. Understanding why is often more valuable than the estimate itself.
Hidden complexity often emerges. The person who estimated high might be aware of an integration challenge or technical debt that others overlooked.
Different assumptions become visible. Maybe one person assumed the existing API would work, while another assumed it would need modification.
Scope ambiguity surfaces. Perhaps the story can be read two ways, and people estimated different interpretations.
These discoveries improve the estimate, but more importantly, they improve the team's understanding of the work. Problems identified during Planning Poker are far cheaper to address than problems discovered during implementation.
Running effective planning poker sessions
Several practices improve Planning Poker effectiveness.
Timebox discussions. It's easy to spend twenty minutes debating a single story. Set limits (2-3 minutes per story) and move on if consensus isn't reached - very high-effort stories might need to be broken down anyway.
Estimate relative to reference stories. Teams develop intuition over time. A story that's "about like that API integration we did last sprint" is easier to estimate than one considered in isolation.
Separate estimation from commitment. Estimates are forecasts, not promises. If pressure to hit estimates leads to sandbagging, the estimation process breaks down.
Include diverse roles. Developers, QA, designers, and others who'll touch the work should participate. Each brings perspective others might miss.
Avoid interruptions. Planning Poker requires focused attention. Schedule sessions where the team can engage fully.
Common planning poker mistakes
Averaging instead of discussing misses the point. If three people estimate 3 and two estimate 8, the answer isn't 5. The team should understand why those two people see more effort.
Estimating too granularly wastes time. If stories are so small that estimates are 1 vs. 2, the precision isn't valuable. Save Planning Poker for stories with meaningful estimation uncertainty.
Letting one person dominate defeats the purpose. If the senior developer always speaks first during discussion (and others always agree), you've reintroduced the bias Planning Poker was designed to eliminate.
Treating estimates as commitments creates perverse incentives. If people are held to their estimates, they'll pad them. Estimates should be honest forecasts, not negotiated targets.
Planning poker and continuous improvement
Over time, teams should compare estimates to actuals. Which types of stories are consistently over- or under-estimated? What patterns predict estimation errors?
This feedback loop improves future estimates. It also helps teams identify systemic issues - if integration stories are always under-estimated, that's actionable insight about where complexity hides.
