What Is Planning Poker? A Complete Guide for Agile Teams

Planning poker — also called scrum poker — is a consensus-based estimation technique used by agile software development teams. Each team member privately selects a numbered card representing their effort estimate for a user story, then everyone reveals their cards simultaneously. The simultaneous reveal is the key mechanic: it prevents anchoring bias, where one person's early opinion influences everyone else.

The technique was first described by James Grenning in 2002 and later popularized by Mike Cohn in his book Agile Estimating and Planning. Today it is one of the most widely used estimation methods in scrum and agile teams around the world, from two-person startups to organizations with hundreds of developers.

Unlike traditional estimation where a project manager assigns hours, planning poker distributes the estimation responsibility across the entire team. This collective intelligence approach consistently produces more accurate estimates because it leverages the diverse perspectives of developers, testers, designers, and other team members who each see different aspects of the work involved.

A planning poker session follows a structured but lightweight process. The product owner or scrum master presents a user story to the team, explains the acceptance criteria, and answers any clarifying questions. Once everyone understands the scope, each participant independently selects a card from their deck that represents their estimate.

On a count of three, everyone flips their cards face-up at the same time. If all estimates are the same or very close, the team records that number and moves on. If there is significant disagreement — say one person plays a 3 and another plays a 13 — the outliers explain their reasoning. The person who estimated low might say "I think we can reuse the existing component," while the high estimator might counter with "but we need to handle the edge case with legacy data migration."

After this brief discussion, the team votes again. This cycle of vote-discuss-revote continues until the group converges on a number, which usually happens within two or three rounds. The goal is not mathematical precision but rather shared understanding of the work involved.

The entire process for a single story typically takes between two and five minutes. A well-run session can estimate 15 to 25 stories in an hour, making it one of the most efficient estimation techniques available.

Most planning poker decks use a modified Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, and a question mark card. Some teams also include a 0.5 for trivially small items. The question mark means "I have no idea" or "I need more information before I can estimate."

But why Fibonacci and not a linear scale like 1 through 10? The answer lies in human psychology and the nature of estimation uncertainty. As work items grow larger, our ability to distinguish between effort levels decreases. The difference between a task that takes 2 hours and one that takes 3 hours is clear. But the difference between something that takes 37 hours and something that takes 42 hours is nearly impossible to perceive.

The Fibonacci sequence naturally encodes this increasing uncertainty. The gaps between numbers grow as the numbers get larger, which matches our decreasing estimation precision. When you play an 8 instead of a 5, you are saying "this is meaningfully larger." But you are not claiming to know the exact effort — you are acknowledging the inherent imprecision of estimating complex knowledge work.

Some teams prefer T-shirt sizes (XS, S, M, L, XL) or powers of 2 (1, 2, 4, 8, 16). Each scale has trade-offs, but Fibonacci remains the most popular because it strikes the right balance between granularity and simplicity.

Eliminates anchoring bias. When a senior developer says "I think this is a 2" before anyone else speaks, the rest of the team unconsciously adjusts their estimates toward that number. Simultaneous card reveals prevent this entirely. Every voice carries equal weight regardless of seniority.

Surfaces hidden complexity. Divergent estimates are not failures — they are discoveries. When one developer estimates 3 and another estimates 13, it almost always means they are making different assumptions about scope, approach, or risk. The discussion that follows uncovers these differences before they become problems during implementation.

Builds shared understanding. The estimation discussion forces the team to talk through how they would implement each story. This shared understanding reduces the chance of misaligned expectations, rework, and mid-sprint scope surprises.

Improves over time. Teams that practice planning poker regularly become better estimators. They develop a shared mental model of what a "5" means in their context, and their velocity becomes more predictable sprint over sprint.

Keeps it fun. The game-like format keeps estimation sessions engaging. Compared to hours of spreadsheet-based estimation, planning poker is social, interactive, and often entertaining — especially when estimates reveal wildly different assumptions.

Estimating in hours, not relative effort. Story points measure relative complexity, not calendar time. A story that is a 5 is roughly twice as complex as a story that is a 3. Do not try to convert points to hours — it defeats the purpose of abstract estimation.

Letting the loudest voice dominate. After the reveal, the discussion should be structured. Ask the outliers to speak first. If the highest and lowest estimators always defer to the majority, the team is not getting the benefit of diverse perspectives.

Spending too long on one story. If the team cannot converge after three rounds, either the story needs to be broken down into smaller pieces, or more information is needed from the product owner. Set a timebox of five minutes per story and move on.

Estimating stories that are too large. Any story above a 13 should probably be split. Large stories carry disproportionate uncertainty, and breaking them down into smaller, better-understood pieces produces more reliable estimates and smoother sprint execution.

Skipping the discussion. The conversation between rounds is where the real value lives. If your team is just voting and recording numbers without discussing the disagreements, you are going through the motions without gaining the benefit.

Planning poker was originally played with physical cards in a conference room, but remote and hybrid work has made digital tools essential. Online planning poker tools like ScrumChamps allow distributed teams to run estimation sessions in real time, with everyone seeing the reveal simultaneously regardless of their location or time zone.

Remote planning poker actually has some advantages over the physical version. Digital tools automatically track vote counts, highlight consensus, and record results — all bookkeeping that someone had to do manually with physical cards. They also make it easier to include team members who might otherwise be excluded from in-person sessions.

The key to successful remote planning poker is the same as any remote ceremony: keep cameras on, minimize multitasking, and make sure everyone has a chance to speak during the discussion rounds. The estimation quality depends on the quality of the conversation, not the medium.

Starting a planning poker session is simple. You need a team of 3 to 10 people, a backlog of user stories to estimate, and a shared tool. If your team is co-located, physical Fibonacci card decks work fine. For remote or hybrid teams, a digital tool like ScrumChamps lets you create a room, share a link, and start estimating in seconds — no account creation required.

For your first session, start with stories the team is already familiar with. Pick 5 to 10 items from the backlog that have clear acceptance criteria. Walk through the process slowly for the first few stories, then pick up speed as the team gets comfortable with the rhythm of vote-discuss-revote.

Most teams find their groove within two or three sessions. After that, planning poker becomes a natural part of the sprint cadence — a focused, efficient way to turn a pile of vague requirements into a shared understanding of the work ahead.