What is Scrum Poker?

A collaborative estimation technique for agile teams

Introduction

Scrum Poker (also known as Planning Poker) is a consensus-based estimation technique used by agile teams to estimate the effort required to complete user stories or tasks. It helps teams reach agreement on story points or time estimates through discussion and collaboration.

The technique was created by James Grenning in 2002 and popularized by Mike Cohn. It's based on the Wideband Delphi method and uses a deck of cards with numbers representing estimates.

Watch a Tutorial

Video: Planning Poker explained by Atlassian

How to Play Scrum Poker

1

Create a Room & Gather Your Team

Start by creating an estimation room and sharing the room code with your team members. Everyone joins the same room so they can participate in the estimation session together.

Tip: Make sure all team members who will be working on the story are present. This includes developers, designers, QA, and anyone else who understands the work involved.

2

Present the User Story

The product owner or scrum master presents the user story or task to be estimated. Make sure everyone understands what needs to be built, including acceptance criteria, dependencies, and any technical considerations.

Important: Clarify any questions before voting begins. Ambiguity leads to inconsistent estimates.

3

Select Your Estimate Privately

Each team member privately selects a card representing their estimate. Use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34) or similar scale. The "?" card can be used if you need clarification.

Why Fibonacci?

The Fibonacci sequence reflects the uncertainty in estimation. The larger the number, the more uncertainty exists. This prevents false precision and encourages discussion when estimates differ significantly.

4

Reveal All Votes Simultaneously

Once everyone has voted, reveal all estimates at the same time. This prevents anchoring bias where later voters are influenced by seeing earlier votes.

Key benefit: Simultaneous revelation ensures independent thinking and honest estimates from all team members.

5

Discuss Differences

If estimates differ significantly, team members discuss their reasoning. The person with the highest estimate explains why they think it's complex, and the person with the lowest estimate explains why they think it's simple.

What to discuss:

  • Technical complexity or unknowns
  • Dependencies on other work
  • Assumptions about requirements
  • Past experience with similar tasks
6

Re-estimate Until Consensus

After discussion, team members vote again. Repeat this process until the team reaches consensus or agrees on a final estimate. Usually, 2-3 rounds are enough.

Consensus doesn't mean everyone agrees: It means everyone can accept the estimate and commit to it. If estimates are close (e.g., 5 and 8), you might average them or take the higher value.

Best Practices

✓ Keep Stories Small

Break down large stories before estimating. If a story is estimated at 21 or 34, it's probably too big and should be split.

✓ Use Relative Estimation

Compare stories to each other, not to absolute time. A "5" should be roughly twice as complex as a "3", regardless of actual hours.

✓ Include the Whole Team

Everyone who will work on the story should participate. Different perspectives lead to better estimates.

✓ Timebox the Discussion

If discussion goes on too long, take a break or defer the story. Use a timer to keep discussions focused and productive.

Benefits of Scrum Poker

🎯 Better Estimates

Multiple perspectives lead to more accurate estimates than individual guesses.

💬 Team Alignment

Discussion ensures everyone understands the work and its complexity.

⚡ Faster Planning

Structured process prevents endless debates and keeps planning sessions focused.

📊 Shared Understanding

Team members learn from each other's perspectives and reasoning.