Planning Poker
- Pronunciation
- PLAN-ing POH-ker
In short
Planning poker is a team estimation technique in which members privately pick estimate cards for a task, reveal them at once, then discuss the differences.
What is planning poker?
The technique was described by James Grenning in 2002 and popularized by Mike Cohn's book on agile estimation. The team looks at a user story, asks the product owner questions, and then each person chooses a card, usually from a modified Fibonacci sequence such as 1, 2, 3, 5, 8, 13, 20 and 40, representing story points.
Everyone reveals at the same moment, which prevents anchoring, where the first number spoken pulls everyone else toward it. If the estimates are close, the team takes the common value. If they differ widely, the people with the highest and lowest cards explain their reasoning, and these conversations often uncover hidden work, risks or misunderstandings before anyone writes code.
The growing gaps between numbers reflect that big tasks are harder to estimate precisely, so there's no point arguing whether something is a 19 or a 21. Many teams treat a very high card as a signal to split the story. Remote teams use online planning poker tools that hide votes until everyone has chosen.
A common misconception is that the numbers are the main value. The estimates are rough and only meaningful within the same team; the real benefit is the shared understanding the discussion creates. Teams that can't agree after one short round usually need more information, not more voting.
Key takeaways
- Planning poker is a team technique for estimating effort.
- Everyone chooses a card privately and reveals at the same time.
- Cards follow a growing sequence such as 1, 2, 3, 5, 8, 13.
- Large differences trigger discussion that exposes hidden work.
- The conversation matters more than the exact number.
Readers ask
Why does planning poker use Fibonacci numbers?
Because the growing gaps reflect growing uncertainty. It's realistic to tell a 2 from a 3, but not a 20 from a 21, so the scale forces estimates to stay rough for big tasks.
What happens if estimates differ a lot?
The people with the highest and lowest estimates explain their reasoning, the team discusses, and then everyone votes again. Big differences often reveal different assumptions about the work.
Do you have to use planning poker in Scrum?
No. Scrum doesn't prescribe any estimation technique. Planning poker is popular, but teams also use t-shirt sizes, simply count stories, or skip estimates and rely on small, similar-sized items.
See also
- Story PointsTeams & Process, p. 28Story points are a unit Agile teams use to estimate the relative size of work items, combining complexity, amount of work, and uncertainty rather than hours.
- User StoryTeams & Process, p. 30A user story is a short, plain-language description of a feature told from the user's point of view, explaining who wants it, what they want, and why.
- ScrumTeams & Process, p. 21Scrum is an Agile framework in which a small team delivers a product in fixed-length cycles called sprints, using defined roles, events, and artifacts.
- Sprint PlanningTeams & Process, p. 27Sprint planning is the Scrum event that starts each sprint, where the team agrees on a sprint goal, selects backlog items it can finish and plans the work.
- VelocityTeams & Process, p. 31Velocity is the amount of work an Agile team completes in one sprint, usually the total story points of finished items, used to forecast future sprints.
- Product BacklogTeams & Process, p. 17The product backlog is a single ordered list of everything a team might do to improve a product, such as features, fixes, and technical work.
Spotted a mistake or something missing on this page?Suggest an edit