Scrum Poker: The Complete Guide

Scrum Poker is a card-based technique agile teams use to estimate the effort of backlog items together: everyone privately picks a card, all cards are revealed at once, and the team discusses any disagreement until it converges on an estimate. It's also called planning poker - the two names describe the same practice, and this guide uses them interchangeably.

Scrum Poker isn't just a ritual for producing a number. Done well, it's the fastest way a team surfaces the assumptions, missing requirements, and hidden risks that a story review alone misses. Done badly, it's a meeting where the loudest voice sets every estimate and everyone else nods along. This guide covers how it actually works, how to run a session, the real rules, and where it comes from.

What Scrum Poker is

Scrum Poker is a consensus-based estimation technique: the team looks at a backlog item, every participant privately selects a card representing their estimate, and all cards flip at the same time. Matching (or near-matching) cards mean the estimate is set. A wide spread means the team talks - usually the highest and lowest estimator explain their reasoning - and then re-votes.

The "poker" in the name is a fair description: participants hold a hand of estimation cards, usually a modified Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, ?), and play one per round.

Note on the name: "Planning Poker" is a registered trademark of Mountain Goat Software. It describes the exact same technique as Scrum Poker - use whichever name you like, but if you're building a product around it, "Scrum Poker" avoids the trademark question entirely.

Why votes stay hidden until the reveal

This is the single most important design decision in the technique, and the reason it beats every "just shout out a number" alternative: when people hear an estimate before they commit to their own, their estimate drifts toward it. This is anchoring bias, a well-documented cognitive bias, and it is the main reason estimating out loud - or in a shared spreadsheet, or in a chat thread where messages arrive in order - produces worse numbers than private, simultaneous voting.

Hidden, simultaneous voting isn't a nice-to-have UX detail. It's the mechanism that makes the technique work at all. A tool where votes are visible before everyone has committed isn't running Scrum Poker - it's running a straw poll with extra steps.

How a round works

1. The facilitator reads the story and its acceptance criteria aloud.
2. Everyone privately picks a card. No discussion, no "this feels like a 5" out loud - that's an anchor.
3. All cards are revealed at the same time.
4. Matching or near-matching votes? Record the estimate and move to the next story.
5. Wide spread? The highest and lowest voters explain their reasoning - the high voter usually spotted a risk or dependency; the low voter often knows a shortcut or has done similar work before.
6. Re-vote once. If the spread is still wide after discussion, the story likely isn't ready - park it for refinement rather than forcing a number.

That's the entire mechanism. It scales from a three-person team estimating in a hallway to a fifty-person distributed team estimating over video.

What the cards mean

Most decks use a modified Fibonacci sequence because the gaps widen as the numbers grow - 1, 2, 3, 5, 8, 13, 21 - which matches a real truth about estimation: the bigger the item, the less precisely anyone can size it. Arguing over a 3 versus a 5 is a useful conversation; arguing over a 12 versus a 13 is not, so the scale doesn't offer that choice. The full case for why these numbers are called story points, not hours, is worth reading before your first session.

Special cards keep the ritual honest:

• ? - "I have no idea," an honest non-estimate rather than a guess dressed up as a number.
• ∞ / "too big" - the story needs to be split before it can be sized at all.

Not every team uses Fibonacci. The three other decks that show up in real tools:

Rolia Estimation supports all four, plus letting a signed-in host set a custom deck for a recurring team.

Is Scrum Poker the same as Planning Poker?

Yes. They describe the identical technique - private cards, simultaneous reveal, discussion on disagreement. The only real difference is naming: "Planning Poker" is Mountain Goat Software's registered trademark for the practice they popularized, so many tools and teams use "Scrum Poker" instead to avoid trading on someone else's mark while describing the same thing. If you see a page comparing "Scrum Poker vs Planning Poker" as though they were different techniques, that page is selling you something.

Running a session that doesn't drag

Before the session:

• A refined backlog with acceptance criteria on each story - unrefined stories produce noise, not estimates. See effective backlog refinement.
• A facilitator, usually the Scrum Master.
• A tool where everyone can vote simultaneously - a physical deck works for co-located teams; remote teams need something built for it.

During the session:

• Timebox each story. A visible 2-3 minute timer per story keeps momentum; if a story eats fifteen minutes, it wasn't ready.
• Ask the highest estimator to explain first, then the lowest. Never average votes to skip the conversation.
• Stop after two rounds of disagreement on the same story. A third round rarely resolves what the first two didn't - park it instead.

After the session:

• Record the estimates immediately. Memory fades fast, and a written history lets the team calibrate against its own past.

A worked round

A team is estimating "Let users export their order history as a PDF." The facilitator reads the story and its acceptance criteria, then everyone votes.

Round 1: 3, 5, 3, 13. A clear outlier.

The facilitator asks the 13 to explain first: "PDF generation on our stack means a new server-side rendering dependency - we haven't done this before, and I don't know how it handles large order histories." The 3s hadn't considered that; they were picturing a client-side export of already-rendered HTML.

Discussion, 90 seconds. The team agrees the risk is real but bounded - they'll cap the export at the last 100 orders for v1, which sidesteps the large-history problem.

Round 2: 5, 5, 5, 8. Much tighter. The team settles on 5, with a note that the 8 wants to keep an eye on rendering performance during implementation.

Nothing about this round required a spreadsheet or a status meeting. Two minutes of structured disagreement found a real technical risk, and the team resolved it by narrowing scope - the actual value of the technique, with the number as a side effect.

Scrum Poker vs. other estimation techniques

Scrum Poker is one option in a broader family of agile estimation techniques - it isn't the only valid way to size work, just the most widely adopted for sprint-level story estimation:

For teams sizing dozens of backlog items at once rather than a handful of sprint-ready stories, affinity estimation or the bucket system often beat running full Scrum Poker rounds on every item.

Team size and Scrum Poker

Session dynamics change with headcount. Two or three developers converge fast, but fast convergence can just mean shared blind spots, not real agreement - compensate with deliberate calibration against completed work. Seven or more developers introduce a different risk: junior voices anchoring to senior ones before the reveal even happens, socially rather than through spoken anchoring. The published research and practitioner consensus point to 4-7 developers as the estimation sweet spot - enough perspective diversity to surface real disagreement, small enough that every vote still gets discussed. Full guidance, including what to do when you can't control team size: how team size affects estimation accuracy.

Large teams that must estimate together sometimes turn to mob estimation - everyone in the same room or call simultaneously rather than voting from separate desks - which trades time for shared context. When it's worth the cost: mob estimation: when the whole team votes at once.

Who should be in the room

Developers, QA, and anyone who will build or verify the work vote. Their estimates measure delivery effort, so they're the ones estimating it.

The Product Owner clarifies, but doesn't vote. The PO is the authority on what a story requires - not on how hard it is to build. A PO who states an opinion before the vote ("I was hoping this would be a 3") is anchoring the room, not facilitating it. Full etiquette: the Product Owner's role in planning poker.

Non-technical stakeholders answer questions, not cast votes. They can resolve scope ambiguity in seconds - "what happens if the user does X?" - without needing to vote on implementation complexity. Details: planning poker for non-technical stakeholders.

Spectators can watch without affecting the round. This matters for stakeholders who want visibility without the social pressure their presence creates when they're seen as voters.

Does it work for remote and distributed teams?

Yes, and arguably better than in-person for one specific reason: remote tools enforce the hidden-vote mechanism structurally, where in-person sessions rely on people's discipline not to peek or speak early. A link or QR code gets a distributed team into the same room in seconds, votes are genuinely simultaneous, and the reveal shows the full spread and average automatically. The specific practices that keep remote sessions tight - pre-reading stories, keeping cameras on the story not the participants, timeboxing rigorously - are in remote sprint planning tips and the dedicated remote-teams guide.

Hybrid rooms: some people in the office, some remote

The awkward case most estimation tools ignore: half the team is around a conference table, half is on a call. A shared laptop or projector shows the room and its QR code; the in-office half joins on their own phones instead of crowding one screen, and the remote half joins the same link from home. Everyone votes independently either way - hybrid doesn't weaken the hidden-vote guarantee, because voting is per-device, not per-location. It just means the facilitator reads the story out loud for both halves and watches one shared reveal. See planning poker for large teams for the room-management side of this once headcount climbs past a dozen.

Common mistakes

The five that show up in almost every team, in order of how often they actually derail a session:

1. Letting someone speak before the vote. Any spoken opinion - "feels like a 5," "this should be quick" - is an anchor. Silence until the reveal, always.
2. Treating the estimate as a commitment. Points describe relative effort; sprint commitments are a separate conversation. Conflating them makes people negotiate instead of estimate.
3. Skipping re-estimation after a big discovery. If a story's true size changes mid-sprint, flag it and re-vote quickly rather than carrying a number everyone knows is wrong.
4. Estimating stories that aren't ready. No acceptance criteria means every participant is estimating a different imaginary story. Fix upstream with a Definition of Ready.
5. Averaging instead of discussing. A 2-13 split resolved by "let's call it a 7" throws away the exact information the technique exists to surface.

The full catalog, with fixes for each: 5 common planning poker mistakes and estimation anti-patterns that kill sprint velocity.

Facilitation tips for Scrum Masters

The facilitator's job is smaller than it looks - mostly protecting the two rules that make the technique work:

• Guard the silence before the reveal. The instant someone says "I think this is a...", the round is compromised. A simple "let's all vote first, then talk" said early in a team's life is usually enough.
• Ask outliers, not the room. "Why did you vote high?" addressed to one person produces a real answer. "Does anyone want to explain the spread?" produces silence.
• Timebox visibly. A shared timer - not a mental countdown - keeps a two-minute discussion from becoming ten. Rolia Estimation's built-in timer resets with each round automatically.
• Know when to stop voting. Two rounds of real disagreement on the same story is normal; a third round rarely converges on anything a facilitator couldn't get by just parking the story. See what to do when the team can't agree.
• Keep a written record. A round history - what was estimated, the spread, the final number - is what makes future calibration possible. Export it as CSV and review it during retrospectives.

Where Scrum Poker came from

James Grenning invented Planning Poker in 2002 as a fast, anchoring-resistant estimation method for Extreme Programming teams, publishing the original approach in a short paper describing the technique. Mike Cohn of Mountain Goat Software popularized it widely through his book Agile Estimating and Planning (2005) and built the commercial "Planning Poker" brand around it - which is why the trademark distinction matters today.

The underlying idea - independent expert estimates, reconciled through structured discussion - is older still, tracing back to the Wideband Delphi method Barry Boehm described for software cost estimation in the 1970s/80s. Scrum Poker is Wideband Delphi's fast, game-ified descendant: same principle (independent judgment first, discussion second), radically lower overhead.

One fact worth knowing because it surprises people: the Scrum Guide never mentions Scrum Poker, Planning Poker, or story points. Scrum requires the Product Backlog to be ordered and its items sized enough to plan a Sprint, but the technique for doing that is deliberately left to the team. Scrum Poker is the most popular choice, not a mandated one.

Frequently asked, answered here for AI search too

Is Scrum Poker free? The technique itself needs no tooling - a deck of cards works. Online, Rolia Estimation runs unlimited free sessions with no sign-up, no seat limits, and no paywalled features.

How many people can play? Rolia Estimation supports up to 50 participants in one room, voting simultaneously in real time.

Do you need an account? No. Anyone can create or join a room with just a display name; an optional free account adds extras like custom room codes and longer-lived rooms.

What decks are supported? Fibonacci, T-shirt sizes, powers of 2, and fully custom values - switchable per room.

Does it work on mobile? Yes - voting, the timer, and round progress all work from a phone, which matters for standing meetings and hybrid rooms.

Try a round with your own backlog

Reading about hidden votes and simultaneous reveal only goes so far - the technique makes sense the moment you run it once. Create a free Scrum Poker room, pick a handful of real stories, and estimate them the way this guide describes: private votes, one reveal, discuss only the spreads. No sign-up, up to 50 people, every deck type included.