What is Planning Poker?

Estimation in software development is hard. People are terrible at predicting how long things will take — especially when they estimate alone. Planning poker fixes this by turning estimation into a team exercise that surfaces disagreements early and drives toward consensus.

If you've never heard of it, or you've done it but it felt like a waste of time, this post will help you understand what planning poker is, why it works, and how to do it well.

What Planning Poker Is

Planning poker is a consensus-based estimation technique used in Agile and Scrum teams. Instead of one person guessing how long a feature will take, the entire team estimates together using a deck of numbered cards.

It's typically done during sprint planning or backlog grooming sessions when the team needs to size user stories before committing to a sprint.

The name sounds silly, but don't let that fool you. It's one of the most effective estimation tools I've used in over a decade of running Agile teams.

How It Works

Here's the basic flow:

1. Present the Story

The Product Owner or Scrum Master presents a user story to the team. They explain the business context, the acceptance criteria, and answer any clarifying questions. If you're not familiar with how to write and refine stories, check out my guide on how to groom user stories.

2. Discuss Briefly

The team talks through the story for a few minutes. What's the scope? Are there unknowns? Dependencies? The goal isn't to design the solution — it's to make sure everyone understands what's being estimated.

3. Everyone Votes Simultaneously

Each team member selects a card representing their estimate and places it face-down on the table (or submits it in a digital tool). Once everyone has chosen, all cards are revealed at the same time.

The simultaneous reveal is critical. If people see each other's votes before committing, anchoring bias takes over. The loudest or most senior person's estimate dominates. Planning poker eliminates that.

4. Discuss the Outliers

If the estimates are close — say, mostly 5s with one 3 — the team can quickly agree on a number and move on.

If there's a big spread — say, one person votes 2 and another votes 13 — that's where the real value is. The high and low voters explain their reasoning. Often, one person knows about a hidden complexity the others missed. Or one person has a much simpler approach in mind.

5. Re-vote if Needed

After the discussion, the team votes again. Usually the second round converges. If it doesn't, the team can go with the majority, take the higher estimate, or break the story into smaller pieces.

The Card Values

Planning poker uses a modified Fibonacci sequence:

0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89

Some decks also include a ? (unknown — need more information) and a coffee cup (break time).

Why Fibonacci and not linear numbers? Because estimation accuracy decreases as size increases. The gap between 1 and 2 is meaningful. The gap between 21 and 22 is not. The Fibonacci sequence forces the team to think in relative buckets rather than false precision.

Mike Cohn wrote one of the best explanations of this concept. I recommend his piece on what story points are and how they work.

Story Points, Not Hours

Planning poker estimates in story points, not hours or days. Story points measure relative effort, complexity, and uncertainty — not calendar time.

A 5-point story is roughly twice as complex as a 3-point story and half as complex as an 8-point story. The team calibrates this over time by comparing new stories against previously completed ones.

This distinction matters. Hours encourage false precision and sandbagging. Story points encourage honest, relative sizing. Over a few sprints, the team's velocity (average story points completed per sprint) becomes a reliable predictor of capacity.

Tips for Better Sessions

Keep it moving. If a story sparks more than five minutes of debate, it probably needs to be broken down or sent back for refinement. Don't let estimation sessions turn into design sessions.

Use a reference story. Pick a well-understood, recently completed story and declare it your "baseline" — say, a 3. Estimate everything relative to that. It gives the team a shared anchor.

Include everyone who does the work. If only senior developers estimate, you'll miss the perspective of testers, junior developers, and anyone else who contributes to delivery.

Estimate uncertainty, not just effort. A story that's straightforward but large might be a 5. A story that's small but involves a system nobody understands might also be a 5. Both effort and risk factor into the number.

Don't obsess over precision. The goal is to be roughly right, not exactly right. If the team is debating between a 5 and an 8, pick the 8 and move on. You'll correct over time through velocity.

Common Mistakes

Letting one person dominate. The whole point is independent estimation. If the tech lead always speaks first and everyone adjusts to match, you've lost the benefit.

Estimating in hours. If people start saying "that's about two days," redirect them to relative points. Hours create a different set of biases and false expectations.

Skipping the discussion. If the team votes 3, 3, 3, 13, and you just go with 3 without asking why someone voted 13, you're ignoring valuable information.

The Bottom Line

Planning poker works because it democratizes estimation and forces the team to talk through assumptions. The conversation is the point — the number on the card is just a useful side effect.

If your sprint planning sessions feel like they're producing unreliable estimates, give planning poker a serious try. It won't make estimation perfect, but it will make it a lot less wrong.

For a broader understanding of the framework behind all of this, start with what Scrum is and how it works.