What Is Planning Poker? A Complete Guide to Agile Estimation

Ask five engineers how long a piece of work will take and you will get five answers, the loudest of which usually wins. Planning poker exists to stop that. It is a small structural trick — everyone commits to a number privately, then all the numbers appear at once — and it changes the conversation from negotiation into genuine information sharing.

What planning poker is

Planning poker (also called scrum poker or pointing poker) is a consensus-based estimation technique for agile teams. The team takes one backlog item at a time. Everybody who will do the work privately selects a card representing how much effort they think it involves. When everyone has chosen, all cards are revealed simultaneously. If the numbers agree, the estimate is recorded and the team moves on. If they do not, the high and low voters explain their reasoning and the team votes again.

That is the entire method. What makes it more than a gimmick is the simultaneous reveal. In an ordinary estimation discussion, the first number spoken becomes an anchor — a well-documented cognitive bias where an initial figure drags every subsequent judgement toward it. Say "this is probably a three" out loud and the room will cluster around three, regardless of whether three is right. Hidden votes remove the anchor entirely. Every number on the table is an independent judgement.

The disagreements are the valuable part. When one engineer says 2 and another says 13, the gap is almost never about arithmetic. It is that one of them knows something the other does not: an undocumented dependency, a service that needs migrating first, a requirement that looks trivial and is not. Planning poker is a mechanism for surfacing that knowledge at the cheapest possible moment — before the sprint starts, rather than halfway through it.

Where it came from

James Grenning described the technique in a 2002 paper, written out of frustration with estimation meetings that consumed entire days and produced numbers nobody believed. He was adapting Wideband Delphi, an estimation method Barry Boehm had popularised, which uses rounds of anonymous expert estimates converging through discussion. Grenning's contribution was making it fast enough to use on a whole backlog: cards instead of forms, minutes instead of hours.

Mike Cohn spread it widely through Agile Estimating and Planning in 2005, and it has been standard practice on scrum teams ever since. The vocabulary shifted along the way — "scrum poker", "pointing poker", "story point poker" all describe the same thing — but the mechanic has not changed in twenty years, which is a reasonable signal that it works.

Why teams bother

The obvious answer is "to get estimates", and that is the weakest reason. Estimates produced by planning poker are not dramatically more accurate than estimates produced other ways. What the session buys you is different:

• Shared understanding. By the end of a session, everyone has heard the same explanation of every story. That alone prevents a meaningful share of mid-sprint surprises.
• Early detection of vague stories. A story that produces wildly scattered votes is not a hard story. It is an unclear one. The spread is a diagnostic.
• Everyone speaks. Voting is mandatory and private, so the quietest person in the room contributes a number with exactly the same weight as the most senior. On teams with a steep seniority gradient, this is the single biggest benefit.
• A forecast that improves on its own. Once a team has a few sprints of history, the points they complete per sprint — their velocity — becomes a genuinely useful planning input, without anyone having to promise a date.

How a session actually runs

A session needs a facilitator, the people who will do the work, and someone who can answer questions about scope — usually the product owner. The facilitator and the product owner do not vote. The estimate belongs to the people delivering it.

1. Pick a reference story first. Before estimating anything new, agree on one story the team has already finished and call it a 3 (or a 5 — the specific number matters far less than everyone sharing it). Every subsequent estimate is relative to that anchor. Skipping this step is the most common reason a team's points drift into meaninglessness.
2. Read the story aloud. The product owner describes it and takes questions. Keep this tight — two minutes, not ten.
3. Everyone votes privately. Physical cards face down, or a tool that hides selections until the reveal.
4. Reveal simultaneously. All at once. This is the part that cannot be compromised.
5. Discuss only the outliers. Highest and lowest voter each explain briefly. Not a debate — an exchange of information the others might not have.
6. Re-vote. Usually the second round converges. If a third round does not, stop: take the higher number, or split the story, and move on. Nothing useful happens in round four.

Pace is the thing to watch. Two to three minutes per story is healthy, which puts a sprint's backlog comfortably inside an hour. A story that eats five minutes is telling you it needs splitting, not more discussion.

The deck and what each card means

A standard deck carries the Fibonacci-derived values plus a handful of cards that are not numbers at all:

• 0done already
• 1
• 2
• 3
• 5
• 8
• 13
• 21
• ?unclear
• ☕break

The non-numeric cards earn their place. 0 means the work is already done or is too small to track. The question mark means "I do not understand this well enough to estimate it" — far more useful than a guessed number that gets averaged in as if it were real information. The coffee cup asks for a break, and a facilitator who ignores it will get worse estimates for the rest of the session.

Some decks add ½ for trivial work and ∞ for "this is far too large to estimate as one item". Both are signals rather than sizes. Our breakdown of every card in the planning poker deck goes through when each one is the right thing to play.

Why the numbers are not evenly spaced

New teams often ask why the deck is not simply 1 through 10. The answer is that uncertainty scales with size. A team can size a one-day task fairly precisely. Asked about a three-week task, the honest answer is "somewhere between two and five weeks" — and a scale with a 6 and a 7 on it invites the team to pretend to a precision it does not have.

The Fibonacci sequence widens as it climbs: 1, 2, 3, 5, 8, 13, 21. At the low end, the steps are fine-grained because small work is genuinely knowable. At the high end, the gaps are wide because large work genuinely is not. When the choice is between 8 and 13, the team has to make a real decision instead of splitting a difference.

There is a second effect: the gaps stop the meeting from stalling. Nobody argues about whether something is a 6 or a 7, because neither card exists. We cover this in more depth in why planning poker uses the Fibonacci sequence.

What you are estimating

Planning poker measures story points, and story points are not hours in disguise. A point is a unit of relative size that folds together three things: how much work there is, how complex it is, and how much is unknown. A simple task that touches forty files and a genuinely novel task that touches two can land on the same number for different reasons.

The reason to resist converting points to hours is that people estimate relative size far better than they estimate duration. Ask whether this story is bigger than that one and the answer is usually right. Ask how many hours it will take and the answer is systematically optimistic, because it silently excludes review, testing, the meeting on Thursday, and the thing that breaks. Velocity absorbs all of that automatically: if the team completes 30 points a sprint, that figure already accounts for their real working conditions.

The moment someone writes down "1 point = 4 hours", points become hours with extra steps, and every reason to use them disappears. There is more on this in what story points actually measure.

Numbers are not the only option. Some teams size in t-shirt sizes — XS through XL — which is faster, harder to mistake for a schedule, and well suited to roadmap-level work that is nowhere near ready for a number.

Five things that go wrong

The loudest person votes first

Someone says "this is obviously a 5" before the reveal and the round is dead. Nothing after that is an independent estimate. A facilitator's main job is to shut down pre-reveal numbers.

Estimates become commitments

The fastest way to destroy a team's estimates is to hold them to the numbers. Once people believe an 8 is a promise, every 8 becomes a 13, and the estimates stop carrying information. Points are a planning input, not a contract.

Velocity gets compared between teams

Team A does 40 points a sprint and Team B does 25, so Team A is more productive. This is nonsense — the scales are anchored to different reference stories and are not commensurable. Velocity is only meaningful compared against the same team's own history.

Everything is a 13

If most of the backlog lands at the top of the scale, the stories are too big to plan with. Anything above an 8 should be a candidate for splitting before it enters a sprint.

The session runs for three hours

Estimation quality falls off a cliff after about an hour. Long sessions produce fatigued votes, and fatigued votes are noise. Cap it, take the break when someone plays the coffee cup, and finish the rest tomorrow.

Running it with a remote team

Physical cards do not survive a video call. Holding a card to a webcam is neither simultaneous nor private — people see each other's screens, the person with the worst connection reveals last, and the anchor effect comes straight back in through the side door.

A shared tool solves the reveal mechanically, but distributed teams have two further problems worth naming. Silence reads as agreement on a call in a way it does not in a room, so a facilitator has to ask directly rather than wait. And if the team spans several time zones, someone is always estimating at the wrong end of their day, which is a real input into the quality of their vote. Planning poker for remote and distributed teams covers how to handle both.

Frequently asked questions