What planning poker is
Planning poker is a collaborative estimation technique used by product and software teams. Participants discuss one work item, choose estimate cards independently, and reveal their choices at the same time. The cards usually represent relative effort, complexity, or uncertainty rather than elapsed time.
Simultaneous voting matters because people naturally anchor on the first number they hear. Hidden votes make it easier for every participant to form an independent view. A wide spread of votes is not a failure; it is a signal that the team is working from different assumptions and should talk before committing.
Prepare before inviting votes
A team can only estimate what it understands. Before voting, describe the desired outcome, the important acceptance conditions, known dependencies, and boundaries that are deliberately out of scope. Avoid turning the discussion into a full implementation design, but give participants enough information to identify meaningful risks.
- Estimate one clearly defined item at a time.
- Confirm what “done” includes, such as testing, review, documentation, and deployment work.
- Call out external dependencies and areas where the team has little experience.
- Split an item before voting if it combines unrelated outcomes or is too vague to discuss.
Run the voting round
- The facilitator creates a room, shares the invite, and selects the team’s preferred deck.
- The group reads and discusses the item. Anyone can ask clarifying questions.
- Each voter chooses a card privately. Use ? when more information is required.
- The facilitator reveals all votes after everyone who intends to vote has selected a card.
- The highest and lowest voters explain the assumptions behind their estimates.
- The team discusses new information and votes again until it has enough agreement to proceed.
Facilitate disagreement well
The goal is not to pressure the minority into matching the majority. Ask what each estimate includes and what could make the work unexpectedly difficult. A high vote may reveal security, migration, or integration work. A low vote may reveal an existing component or a smaller interpretation of the requirement.
After the discussion, vote again rather than averaging incompatible assumptions. If the spread remains wide, record the unresolved question, investigate it, or split the item. A precise number is less valuable than a team that understands why the work is uncertain.
Common mistakes to avoid
- Treating points as hours. Relative estimates are more useful when they compare work instead of pretending to predict exact duration.
- Voting before clarification. Fast voting on unclear work creates numbers without shared understanding.
- Letting one specialist estimate for everyone. Different disciplines see different risks.
- Debating indefinitely. When discussion stops producing new information, create a follow-up action and move on.
- Using estimates as performance targets. Estimates support planning; they are not a measure of individual productivity.
After the session
Record the agreed estimate and any important assumptions in the team’s backlog or project system. Revisit an estimate when the scope changes or new evidence invalidates the assumptions. The estimate is a snapshot of the team’s current understanding, not a permanent promise.
Ready to try it? Create a room, or compare the available cards in the estimation scales guide.