What is Planning Poker?

Planning poker (also called Scrum poker) is a collaborative estimation technique used by agile teams to estimate the effort or complexity of work items—typically user stories—during sprint planning. Instead of one person declaring how long a task will take, the entire team participates by simultaneously selecting cards with point values, revealing them together, and discussing any differences.

How Planning Poker Works

The process is straightforward and designed to encourage honest input from every team member:

1. The Product Owner presents a user story — They describe what needs to be built and why it matters.
2. The team discusses the story — Developers and QA ask clarifying questions about requirements, technical approach, and potential risks.
3. Everyone picks a card privately — Each team member selects a card representing their estimate without seeing what others picked.
4. Cards are revealed simultaneously — This prevents anchoring bias where early estimates influence others.
5. The team discusses differences — If estimates vary widely (e.g., one person picked 2 and another picked 13), those individuals explain their reasoning.
6. Re-estimate if needed — After discussion, the team votes again. Usually estimates converge after 1-2 rounds.
7. Consensus is reached — The team agrees on a final estimate (often the mode or a negotiated value).

Why Teams Use Planning Poker

1. Reduces Bias

When estimates are revealed simultaneously, no one is influenced by the first number mentioned. This creates a more honest assessment of complexity.

2. Surfaces Hidden Complexity

When a developer estimates 13 points and a QA engineer estimates 2, the conversation that follows often uncovers assumptions, technical debt, or testing challenges that weren't obvious at first.

3. Improves Team Communication

Planning poker forces the team to have conversations they might otherwise skip. These discussions build shared understanding and reduce surprises mid-sprint.

4. Engages Quieter Team Members

In traditional estimation meetings, the loudest voice often wins. With planning poker, everyone has equal input—a junior developer's 8 carries the same weight as a senior's estimate.

The Fibonacci Scale: Why Those Numbers?

Most planning poker decks use a modified Fibonacci sequence: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. This scale works because:

• It reflects uncertainty — The gaps between numbers get larger as complexity increases. It's easier to tell the difference between a 1-point and 2-point task than between a 20-point and 21-point task.
• It discourages false precision — There's no 6 or 7. If you're debating between those, the story is probably a 5 or an 8, and that's okay—story points aren't hours.
• Special cards add context — A ? means "I don't understand this story" and a ☕ (coffee cup) means "I need a break."

Common Mistakes (and How to Avoid Them)

Treating Story Points as Hours

Story points measure complexity, not time. A 5-point story might take 3 hours or 3 days depending on the developer, interruptions, and unknowns. Focus on relative effort: "Is this story roughly twice as complex as that 3-pointer we did last week?"

Letting One Person Dominate

If the tech lead always "explains" why their estimate is correct after the reveal, planning poker becomes theater. The Scrum Master should ensure everyone's reasoning is heard.

Skipping the Discussion

If estimates are 5, 5, 5, 8, don't just pick 5 and move on. Ask the person who picked 8 what they're concerned about. Sometimes they've spotted a real issue.

Estimating Tasks, Not Stories

Planning poker works best on user stories (customer-facing features), not granular technical tasks. If you're estimating "Write database migration script," you're too deep in the weeds.

Planning Poker for Distributed Teams

Remote-first teams need a digital planning poker tool. Physical cards don't work over Zoom, and typing estimates in chat reintroduces bias (people see earlier responses). A good online tool lets everyone submit their vote simultaneously and reveals all estimates at once.

Look for tools that support:

• Simultaneous reveals — No one sees estimates until everyone has voted
• Real-time sync — Works across devices and time zones without lag
• No signup required — Less friction means higher adoption
• Room codes — Easy to share a link and let people join on any device

When NOT to Use Planning Poker

Planning poker isn't a fit for every situation:

• Single-developer teams — If you're working alone, just estimate based on your gut. The value of planning poker is in the team discussion.
• Maintenance or bug fixes — Small, well-understood work doesn't need a full ceremony. Save planning poker for stories where complexity is unknown.
• Time-sensitive emergencies — If production is down, don't hold a planning poker session. Fix it first, estimate later.

Getting Started

If your team hasn't tried planning poker yet, here's how to introduce it:

1. Run it for just 3 stories — Don't estimate your entire backlog on day one. Start small.
2. Explain the "why" — Make sure the team understands this isn't about micromanagement—it's about shared understanding.
3. Keep it short — If a story takes more than 5 minutes to estimate, it's probably too big. Break it down.
4. Iterate — After a few sprints, look back at your estimates vs. actual complexity. Adjust your scale if needed.

Planning poker isn't perfect, but it's one of the simplest ways to improve estimation accuracy while building team alignment. Give it a shot for one sprint and see if it sticks.