Planning Poker rules: a working agreement for your team
A practical rules reference for participation, private voting, interrupted rounds and disagreements that a number cannot resolve.
The core Planning Poker rules are to estimate the same work, choose cards independently, reveal together and discuss the reasons behind different estimates before recording a result. Agree who votes and when to pause instead of forcing a number.
“This looks like a two, right?” One sentence can change the next vote. Someone who was considering an eight may now feel they have to defend it before showing a card. A few shared rules give everyone room to think before the discussion starts.
The independent vote and reveal are part of the practice described by Agile Alliance. The exception policies below are suggestions to adapt with your team. For preparation and a full meeting agenda, use the step-by-step Planning Poker guide.
In this reference
When votes hide different requirements
A fictional team is estimating “Let an administrator cancel a pending workspace invitation.” The cards are 2, 2, 5 and ?. The conversation sounds like this:
A
2voter: “We just make the existing invitation invalid.”The
5voter: “What if someone accepts it at the same moment?”The
?voter: “If they have already joined, are we supposed to remove them?”
Calling 2 the winner would leave those questions unanswered. The facilitator asks the Product Owner to separate withdrawing an unused invitation from removing an existing member. Removing a member becomes a different requirement; the cancellation item still needs a decision about simultaneous acceptance and cancellation.
This round ends with a question and someone responsible for clarifying it. Once the decision is recorded, the team can estimate the clarified item. No final number is needed yet.
That is the boundary worth protecting: a vote compares people's understanding of the work; it does not decide the product's behavior. These illustrative numbers are not a sizing guide for invitation features.
Rules to agree before voting
| Rule | What it means in practice |
|---|---|
| Size one shared scope | Make the intended behavior and boundaries visible. If the scope changes, the old votes describe the old item. |
| Use one unit and deck | Agree whether you are using story points or another unit. Do not let half the room estimate hours while the other half compares relative size. |
| Let the people doing the work estimate | Include the perspectives needed to finish the item, rather than giving votes according to seniority or job title. |
| Choose privately; reveal together | Avoid announcing a target number, polling people aloud or opening the cards while someone is still choosing. |
| Ask for assumptions behind different cards | Invite low and high reasoning, then other relevant concerns. A minority may have noticed missing work. |
| Give non-number cards an explicit meaning | A question, a skipped estimate and a request for a break convey different things. None is a numerical estimate. |
| Agree how to finish or stop | Record an estimate the team agrees it can use, or capture the question that needs answering first. |
| Reopen an estimate when information changes | New scope or a newly discovered constraint can justify another estimate. A desire to improve a dashboard number does not change the work. |
For story-point calibration, use your own completed reference items. The story-point examples show how to describe their boundaries; the Fibonacci guide covers card spacing and deck choices. Neither a particular deck nor a points-to-hours conversion is required by these rules.
Who votes and who facilitates
In Scrum, sizing is the responsibility of the Developers doing the work, according to the Scrum Guide's Product Backlog section. Here, “Developers” means the people who create a usable Increment, including those who contribute skills beyond writing application code. Scrum does not require Planning Poker or prescribe its exception policies.
For example, a tester might ask, “What should happen if the administrator loses permission halfway through?” That question belongs in the estimate of the whole item. It should not become an isolated QA bid added to separate frontend and backend point estimates.
The Product Owner explains the outcome and helps settle what is included. A facilitator makes sure people can choose without being steered toward a number. Neither role gives its holder an extra vote. If someone also contributes to delivery, make that role clear rather than deciding participation by title alone. Mountain Goat Software's participation guidance describes this distinction.
Before opening the cards, identify the estimators for this item. A spectator does not need to cast a number just to complete the room's participant list.
What to do when a round goes off track
Someone chooses a question mark or skips
“I picked ? because I don't know whether old invitations must keep working.” Now you have a question to answer. Ask what context is missing, rather than quietly dropping the card from the result.
Keep three messages separate:
?: I need an answer before I can estimate.- Skip: I am not giving an estimate for this item.
0, if your deck has it: a numerical choice whose meaning your team has agreed.
Skip is not zero or silent agreement. If it means the team lacks essential knowledge, capture that gap. A break card is a separate request to pause.
A necessary contributor is missing
“Our database specialist dropped off. Can we still estimate?” If the team understands the database work, continue. If that person holds an answer that could change the implementation, capture the question and defer the estimate. Do not count their absence as agreement.
A number slips out before reveal
“Surely this is a two.” Pause and return to what the item includes. Let everyone reconsider privately; if the cards are already open, begin another round. A restart cannot make people forget the number, so explicitly invite reasons for a different estimate.
The requirement changes after the vote
“Actually, it also needs to revoke invitations sent last month.” That may be useful clarification, but it is new information. Update the acceptance conditions before asking for another estimate. The previous result described the previous scope.
The votes still differ, or someone wants a lower number
Still seeing fives and eights? Ask: “What are you including that the rest of us may have missed?” If both sides describe the same work, compare your reference items. If they describe different requirements, settle the scope first.
Existing Agilo demo screenshot with fictional participants. The average is 5.3, but it does not explain the difference between the votes. The Revote button makes another round possible; the team decides whether clarification or another step is needed first.
“We need it this week, so can you make it a three?” is a question about scope and priorities. Ask what can be removed or changed; lowering a card alone removes no work.
Agile Alliance cautions against forced convergence. People can agree on an estimate they will use without all privately preferring the same card. Hear the remaining concerns first, and stop if the number would conceal an unanswered requirement. Neither an average nor the most senior person's choice can answer that question.
A working agreement to copy
Put this in your team's notes and fill in the brackets. Keep it short enough to read before the first vote. These are team agreements, not settings the tool enforces.
Deck and unit: [choose]. References: [link].
Estimators for this item: [names/skills].
Facilitator: [name]. Product questions: [owner].
We agree on scope, choose privately and reveal together.
We do not announce a target number before reveal.
We hear the reasoning behind differences and remaining concerns.
? means ask; skip means no estimate, never zero or agreement.
Our discussion boundary is [time or stopping condition].
Changed scope means updated requirements and a new estimate.
We record a number when the estimators agree they can use it.
If context or essential expertise is missing: question → owner → next step.
We re-estimate for new information, not a preferred total.
Treat the discussion boundary as a prompt to choose the next action. It is not a deadline to manufacture agreement. Revisit the agreement if it repeatedly prevents useful participation or hides uncertainty.
Use the agreement in Agilo
Keep the agreement in your team's notes and use Agilo Planning Poker for the voting. Choose the agreed deck, keep choices hidden until reveal and start another round when a clarification changes the item. Agilo offers question-mark, break and skip options in its built-in systems; your team still needs to agree how to respond to them.
Create a Planning Poker room once the people, scope and rules are clear. For preparation and the full meeting sequence, return to the facilitator's how-to guide.
Sources
- Agile Alliance: Planning Poker — the basic practice and the risk of compulsory convergence.
- The official Scrum Guide — sizing responsibility; it does not mandate Planning Poker.
- Mountain Goat Software: Planning Poker — participation and interpretation of non-number cards.
