About Planning Poker | Complete Guide

A complete guide to the Agile Planning Poker (or Scrum Poker) technique. Learn its fundamentals, history, rules, and best practices.

Introduction

Planning Poker, also known as Scrum Poker, is a consensus-based, gamified estimation technique used in agile software development to measure effort or relative size of development goals. It is widely adopted in frameworks like Scrum, Extreme Programming (XP), and Kanban.

The technique uses a wide-band Delphi method approach, focusing on the collective intelligence of the team to generate more accurate estimates than those made individually.

Fundamentals and Psychology

The main objective of Planning Poker is to mitigate anchoring bias. In cognitive psychology, anchoring occurs when the first piece of information or number suggested in a discussion dominates the decision-making process, influencing subsequent estimates.

By requiring all team members to present their estimates simultaneously and independently (through hidden cards), the method forces individual thinking. The discrepancies revealed in the vote are used as triggers for technical discussions, where members with different experience levels can share insights about risks or facilities that others haven't perceived.

History

The technique was first defined and named by James Grenning in 2002 as a solution to 'analysis paralysis' in planning meetings. It was later popularized by Mike Cohn in the book 'Agile Estimating and Planning' (2005).

Although the term is a trademark of Mountain Goat Software, its use is free for the community, and the technique has become the global standard for sprint planning and backlog management.

The Deck and Scales

Planning Poker estimates don't use hours or days, but rather abstract measurement units called Story Points. The most common scale is the Modified Fibonacci Sequence:

0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100

Scale Rationale

The use of numbers that distance themselves as they grow serves to reflect the inherent uncertainty in complex tasks. It's psychologically easier to differentiate a 2-point task from a 3-point one than to differentiate a 20-point task from a 21-point one. The jump from 13 to 20 (and then 40) indicates that the greater the effort, the less precise human prediction capability becomes.

Special Cards

  • Question Mark (?) The participant doesn't have sufficient information about the task.
  • Infinity (∞) The task is considered too large to be estimated and needs to be broken down (sliced).
  • Coffee Cup Indicates that the team is tired and suggests a break to maintain estimate quality.

Standard Procedure

The process usually occurs during the Sprint Planning ceremony and follows these steps:

  1. The Product Owner describes a user story.
  2. The team discusses technical requirements, acceptance criteria, and dependencies.
  3. Each member chooses a card mentally and keeps it hidden.
  4. All cards are revealed at the same time.
  5. If there's consensus, the value is accepted. Otherwise, the extreme votes (highest and lowest) explain their arguments. After discussion, a new voting round is held until agreement is reached.

Common Errors (Anti-patterns)

  • Arithmetic Mean Usage Calculating the average of votes instead of seeking consensus nullifies the value of technical discussion.
  • Leadership Pressure When managers or 'senior' developers express opinions before voting, inducing the rest of the team to anchoring.
  • Estimate by hour Trying to convert points directly to hours, which ignores variation in focus and productivity between different members.

Digital Implementations and Tools

With the transition to remote work and distributed teams, Planning Poker has evolved from physical decks to synchronous digital platforms. These tools seek to replicate the dynamic of simultaneous card revelation in virtual environments, ensuring the integrity of the method at a distance.

Digital Tool Features

Common FeatureTechnical DescriptionObjective
Simultaneous RevealEnsures that no vote is visible until everyone has voted or the moderator closes the round.Mitigate anchoring bias.
Multiple Scale SupportAbility to switch between Fibonacci, Modified Fibonacci, or T-Shirt Sizing.Adapt the tool to the team's maturity and culture.
Observer ModeAllows non-voting members (like the Product Owner) to follow the discussion in real time.Promote transparency without interfering with technical estimation.