Planning poker is a team estimation technique: discuss one piece of work, choose cards independently, reveal together and compare the assumptions behind the numbers. It is often called Scrum poker. The useful outcome is a shared understanding of the work, with an estimate the team can explain.
An online tool replaces physical cards, but it does not replace the conversation. Keep a voice or video call open alongside PointRoom if you are working remotely.
When is planning poker useful?
Use it for work that is close enough to delivery to discuss concretely, but uncertain enough that several perspectives will help. A small change with an obvious implementation may need only a quick comparison with a reference story. A vague initiative spanning months probably needs discovery and splitting before a useful vote.
The people who will do the work should bring their own perspectives, including implementation, testing, design and operational concerns. A facilitator keeps the conversation moving; a product owner or stakeholder can clarify the intended outcome. Planning poker is optional: Scrum does not require a particular estimation game or point scale.
The rules in six steps
- Introduce one story. Explain the user outcome and what completion includes.
- Ask questions before suggesting numbers. Surface dependencies, acceptance criteria and unknowns.
- Choose a card privately. Use the same scale and reference stories as the rest of the team.
- Reveal together. Do not make a late estimate after seeing somebody else's card.
- Ask the lowest and highest estimators what they included. Discuss the work, not whose number was right.
- Vote again if the discussion changed the picture. Record an agreed estimate, split the story or identify a question to resolve.
A worked example: downloading an invoice
Imagine a team estimating: “A customer can download a PDF invoice from their order history.” The first votes are 3, 3, 5 and 8. The person choosing 3 expects an existing PDF service to handle the document. The person choosing 8 thinks the team must build tax formatting, permissions and a new export service.
The team confirms that the PDF service already exists, but access-control tests are still required. After clarifying those boundaries, the next round is 5, 5, 5 and 5. The second number is useful because the team now agrees on the scope. These example points are illustrative; they are not a recommended estimate for every invoice feature.
What if the team still disagrees?
Ask a narrower question: is the disagreement about how much work there is, how unfamiliar it is, or what is included? Write the missing assumption into the story. If nobody can answer a key technical question, stop voting and investigate it. Repeated rounds do not turn an unknown into knowledge.
An estimate is a working assumption, not a delivery promise or a measure of an individual's performance. Revisit it when the scope changes. If a session becomes a negotiation to make the number smaller, return to the actual work and the decision the estimate needs to support.
Your first-session checklist
- Bring a small, ordered set of stories rather than the entire backlog.
- Choose two or three familiar completed stories as references.
- Agree what the numbers represent before the first vote.
- Keep votes hidden until the reveal and make room for quieter participants.
- Finish with recorded estimates or explicit follow-up questions.
Sources and further reading
For the underlying methods and framework, start with these primary sources. Worked examples and suggested agendas above are illustrative.
A shared estimate starts with a shared table.
Create a free room, invite your team and try one clear story. No signup needed.
Create a free planning poker room