The Origins of Planning Poker
Planning poker was invented by James Grenning in 2002 as a practical way to handle the estimation challenges he was observing in extreme programming (XP) teams. Grenning observed that traditional estimation approaches — where an expert gives a number and the team adjusts — produced anchored estimates rather than independent ones.
The technique was later popularised by Mike Cohn in his 2005 book Agile Estimating and Planning. Cohn added the Fibonacci card deck, formalized the rules, and registered the "Planning Poker" trademark. The term has since entered common use and is now used generically to describe any simultaneous-reveal estimation game.
How Planning Poker Works: Step by Step
A planning poker session follows a consistent structure:
- The moderator reads a user story. The product owner or scrum master presents the story and its acceptance criteria. Team members can ask clarifying questions.
- Everyone picks a card privately. Each team member selects the card that represents their effort estimate. No one shares their choice.
- All cards are revealed simultaneously. When everyone is ready, all cards flip at once. This is the core mechanic — it prevents anyone from anchoring on another person's estimate.
- Discuss the spread. If all estimates agree (or are close enough), move on. If there is significant spread, the person with the highest estimate and the person with the lowest each explain their reasoning.
- Re-vote if needed. After discussion, the team votes again. Usually one or two more rounds are enough to reach consensus.
- Record the final estimate and move to the next story.
Why Hidden Voting Is the Key
The simultaneous reveal is not a gimmick — it is the structural property that makes planning poker produce better estimates than alternatives like gut-feel or expert judgment.
The psychological phenomenon it prevents is called anchoring bias: when we hear a number before forming our own opinion, our estimate gravitates toward that number even if our independent judgment would be quite different. In a traditional estimation meeting, the first person to speak (typically the most senior or most vocal) sets an anchor that everyone else adjusts around rather than reasoning from scratch.
Hidden voting forces every team member to commit to a number based on their own understanding of the story before they can be influenced. The resulting spread of estimates is more honest — and the discussion it triggers is more productive — than any amount of open debate.
When Estimates Disagree: The Planning Poker Discussion
A large spread of estimates is not a failure — it is valuable signal. The most informative discussions in planning poker happen when a developer votes 2 and a QA engineer votes 13 for the same story. Their disagreement usually means one of three things:
- Different understanding of scope. The story's acceptance criteria are ambiguous. The solution is to clarify, not debate.
- Different awareness of complexity. One team member knows about a hidden dependency or technical debt that others don't. Surface it.
- Different estimation anchors. Each person is comparing the story to different reference stories. Agreeing on a reference story — "this is definitely bigger than the login flow but smaller than the payment integration" — usually closes the gap quickly.
Planning Poker vs. Other Estimation Techniques
T-shirt sizing is faster and better for rough triage, but produces non-ordinal estimates that are harder to compare or aggregate into velocity.
Three-point estimation (best case, most likely, worst case) captures uncertainty explicitly but is more time-consuming and produces estimates that teams often struggle to use in sprint planning.
Expert judgment (one person estimates for the whole team) is fast but produces anchored estimates and misses the collective knowledge of the team.
Planning poker strikes a practical balance: it is fast enough to estimate a full sprint's backlog in 60–90 minutes, produces estimates that represent the team's collective understanding, and generates the discussion that builds shared knowledge about the work ahead.