What is planning poker?

A common mistake is to treat an estimate as a promise about calendar time. Planning poker deliberately avoids that. Teams estimate the relative size of a piece of work: how much effort it takes, how complex it is, and how much is still unknown. Two engineers may work at different speeds, but they can usually agree that one task is roughly twice the size of another. That relative judgment is far more stable than a guess in hours.

The unit of work in most backlogs is a user story, a small, self-contained description of something a user wants. Stories are often written in the form:

As a team lead, I want to export a report to CSV, so that I can share numbers with finance.

A good story also carries acceptance criteria, the specific conditions that must be true for it to be considered done. Those criteria are what the team reads, questions, and estimates against. If the story is vague, the estimates scatter, which is a useful signal that it needs to be clarified or split before any work starts.

Stories are the classic example, but they are not the only thing a team estimates. Most backlogs are a mix of work item types, and the same play-a-card-and-reveal process applies to all of them:

• Tasks are concrete pieces of work that don't map to a user-facing story, such as upgrading a dependency, writing a migration, or wiring up a new build step. They still take effort and carry uncertainty, so they still get pointed.
• Bugs are estimated on the effort to investigate and fix, not on how annoying they are. A one-line fix and a week-long hunt can wear the same label, so the points are what actually plan the sprint.
• Spikes are time-boxed investigations used when the team can't estimate something yet. The estimate reflects how much digging you're willing to fund before deciding, rather than the size of the eventual solution.
• Chores and tech debt such as refactors, cleanup, and tooling get pointed the same way, so the work stays visible in the plan instead of happening in the cracks.

The rule of thumb is simple: if it takes real effort and lands in a sprint, it is worth estimating. What you point is "how big is this piece of work," whatever type of item the tracker calls it.

Estimates are expressed in story points. A point is not an hour or a day. It is a relative measure that rolls effort, complexity, and uncertainty into a single number. A story worth 2 points is roughly twice the size of a 1-point story; an 8 is meaningfully bigger than a 5.

Because points are relative, they travel well across a team even when individuals work at different paces. Over a few iterations a team learns how many points it typically completes, and that observed pace, its velocity, becomes a far more honest planning tool than any upfront time estimate.

The cards usually follow a Fibonacci-like sequence: 0, 1, 2, 3, 5, 8, 13, 21, and so on. The gaps grow on purpose. When something is small you can tell a 1 from a 2, but nobody can honestly distinguish a 21 from a 22. The widening spacing forces a choice and stops the team from arguing over false precision at the large end.

Each item follows the same short loop:

1. The facilitator puts a work item on the table and reads its acceptance criteria or scope. The team asks questions until they understand it.
2. Everyone privately selects the card that reflects their estimate. No one reveals yet.
3. All cards are turned over at the same moment. This simultaneous reveal is the heart of the method: it stops the loudest or most senior voice from anchoring everyone else.
4. The high and the low estimators explain their thinking. Often one of them knows something the rest of the room didn't.
5. The team re-estimates and repeats until the numbers converge. Perfect agreement isn't required, just enough alignment to commit.

Most decks include a few special cards:

• ? means "I don't have enough information to estimate." A cluster of these means the story isn't ready.
• Coffee means "I need a break," a small, humane pressure valve for long sessions.
• Infinity means "this is too large to estimate and should be broken down first."

The value of planning poker is less in the final number and more in the conversation that produces it. A wide spread of votes is not a failure; it is the team discovering that they were picturing different problems. Estimating privately and revealing together removes anchoring bias, gives quieter voices equal weight, and turns a hidden assumption into a shared understanding before a single line of code is written.

The technique was proposed by James Grenning in 2002 and popularized by Mike Cohn, whose book Agile Estimating and Planning made it a fixture of agile teams. The playful name reflects the format: a hand of cards, played face-down, revealed all at once.