OneMorePoint

Scrum Poker Rules: The Complete Reference

Scrum Poker

Scrum Poker Rules: The Complete Reference

Scrum Poker has fewer rules than people expect - the mechanism is simple - but the edge cases (who votes, what the special cards mean, what happens on a tie) trip up almost every team's first few sessions. This page is the reference for those specifics. For how a round actually flows and why hidden votes matter, start with the complete Scrum Poker guide.

The core rule

Every participant picks a card privately. Nobody's card is visible - to anyone, including the facilitator - until all cards are revealed at once. That's the whole mechanism. Everything else on this page is a detail of how that mechanism gets applied.

Who can vote

Developers and QA vote. Anyone who will build or verify the work is estimating their own effort, so they're the ones with a card in hand.

The Product Owner does not vote. This isn't a suggestion - it's enforced: a PO's role is to clarify what a story requires, not to weigh in on how hard it is to build. If a PO states an opinion before the vote ("I was hoping this would be small"), that's anchoring the room regardless of intent.

Spectators do not vote. Spectators can watch a room live - useful for a stakeholder who wants visibility without the social pressure their presence creates when they're seen as a voter - but they never hold a card.

RoleVotes?
DeveloperYes
QAYes
Product OwnerNo
SpectatorNo

What the cards mean

The standard deck is a modified Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 21, ?

  • 0 - work that's real but trivially small, like a typo fix or a one-line config change. Small enough that a full "1" would distort velocity.
  • 1 through 21 - the actual size scale. The gaps widen on purpose: 1 to 2 is a small step, 13 to 21 is a big one, because nobody can reliably tell "this big" from "this much bigger" once a story gets large. Full reasoning: why Fibonacci gaps widen.
  • ? (question mark) - "I don't understand this well enough to size it." An honest non-estimate, not a guess dressed up as a number. A story with multiple ? votes needs a spike or more refinement before it's re-estimated, not a re-vote.

Not every team uses Fibonacci. T-shirt sizes (XS through XXL), powers of 2 (1, 2, 4, 8, 16...), and fully custom decks are all valid - see the full deck comparison in the main guide.

Who reveals the cards

The facilitator (usually the Scrum Master or whoever created the room) reveals by default. Some rooms allow any participant to trigger the reveal once everyone's voted - useful for smaller, self-organizing teams where a dedicated facilitator role feels unnecessary. Either way, the reveal is a single action that flips every card simultaneously - there's no partial reveal, and no way to see one person's card before the others.

What happens on a tie or a close spread

Matching or near-matching votes (say, 5-5-5-8) mean the estimate is effectively set - the team can note the number and move on, or have a thirty-second conversation about the outlier if it's worth it. A genuinely wide spread (2-3-13) means real disagreement about the work, not noise, and skipping the conversation defeats the purpose of the technique.

Never average a wide spread to skip the discussion. A 2-13 split resolved by "let's call it a 7" discards the exact information the vote surfaced - the fact that someone sees hidden risk and someone else sees a shortcut. Ask the high voter to explain first, then the low voter, then re-vote once.

Re-voting

One re-vote after discussion is normal and expected. If the second round is still wide, that's a signal the story isn't ready - it needs refinement, a spike, or a split, not a third round of the same conversation. Two rounds of real disagreement is healthy; three rarely converges on anything a facilitator couldn't get by just parking the story.

Can you change your vote before the reveal?

Yes - a vote isn't locked in until the reveal happens, so re-picking a card before that point is fine and doesn't count as anchoring (nobody else can see the change either). Voting after the reveal isn't meaningful, since the round's information has already been shared.

What if someone abstains or doesn't vote in time?

A story generally shouldn't reveal until every voting participant (developers and QA) has cast a card - revealing early with missing votes produces an incomplete picture of the spread. If someone is genuinely unable to estimate a story (they weren't involved in the relevant part of the codebase, for instance), a ? vote is the honest move, not silence.

Put the rules into practice

Reading the rules only goes so far - the mechanism makes sense the moment you run it once. Create a free room, pick a real story, and vote it the way this page describes: private cards, one reveal, discuss only the outliers.

Frequently asked questions

Not in the standard version of the technique - their input happens through clarifying the story, not through casting an estimate. Some teams relax this only for very small teams where the PO is also a hands-on contributor.

Put it into practice

Create a free Scrum Poker room and estimate with your team - no sign-up needed.