One More Point

What is Scrum Poker?

Scrum Poker is a card-based technique that agile teams use to estimate the effort of user stories in their product backlog. It is also widely known as planning poker; the two names describe the same practice.

The idea is simple. The team looks at a story, every participant picks an estimation card in private, and all the cards are revealed at the same time. If the numbers agree, the estimate is recorded. If they differ, the team discusses why and votes again.

Votes stay hidden until the reveal for a good reason. When people hear a number before they estimate, their own estimate drifts toward it. This is anchoring bias, and it is the main reason that estimating out loud produces poor results. Hidden, anonymous voting keeps every estimate independent.

Scrum Poker works because it combines individual judgment with team discussion. Each person commits to a number first, and the conversation that follows surfaces assumptions, missing requirements, and hidden risks, often the most valuable part of the session.

Start a free Scrum Poker session

One More Point is a free planning poker tool built around that exact loop. Create a room, pick a deck, and share the link, room code, or QR code with your team. Teammates join as guests from any device. No account, no download, no sign-up.

Everyone votes in private. Votes sync in real time, and when the last card is in, the host reveals them all at once, or turns on auto-reveal to flip them automatically. Discuss the spread, start the next round to re-vote, and continue until the team agrees.

Every completed round is saved to the room history, and anyone in the room can download it as a CSV when the session ends.

How planning poker works, step by step

A planning poker session follows the same loop for every story. Here is the full sequence a facilitator walks through, whether the team shares an office or is spread across time zones.

1. Select a user story. The Product Owner or facilitator picks the next story from the product backlog and shares it with the team.
2. Review the details. The team reads the description and acceptance criteria together, so everyone estimates the same piece of work.
3. Ask clarifying questions. Anything unclear gets asked now. What counts as done? Which systems are involved? Is there a design?
4. Choose an estimation deck. Most teams use the Fibonacci deck for story points. T-shirt sizes or a custom deck work too; pick one and stay consistent.
5. Vote independently. Each participant selects a card in private. No numbers are said out loud, and nobody can see anyone else’s vote.
6. Reveal all votes at once. When everyone has voted, the cards flip at the same time. The spread is honest because no one anchored on anyone else.
7. Discuss the high and low votes. Ask the highest and lowest voters to explain their reasoning. They usually know something the rest of the team missed.
8. Vote again if needed. After the discussion, run another round. Estimates tend to converge quickly once assumptions are out in the open.
9. Record the agreed estimate. Write the final number on the story. In One More Point, every round lands in the room history automatically.
10. Move to the next story. Start the next round and repeat. Most teams settle into a rhythm of a few minutes per story.

Consensus does not mean everyone shows the exact same card. It means the team understands the work the same way and can stand behind one number. If a 5 and an 8 remain after discussion, the team agrees which one to record and moves on.

New to facilitating? Our guide to running your first planning poker session covers preparation, pacing, and the surprises to expect.

Why Scrum teams estimate in story points

Story points measure the relative size of a piece of work, not the time it will take. A 5-point story is bigger than a 3 and smaller than an 8. That is all the number claims.

People are unreliable at guessing hours, but surprisingly good at comparing. "This is about twice the size of the login page we built last sprint" is a judgment teams get right far more often than "this will take 14 hours." Story point estimation leans on that strength by comparing new work against stories the team has already delivered.

A story point blends four things at once:

• Complexity. How hard is the problem, regardless of how long it takes?
• Uncertainty. How much is unknown or still to be discovered?
• Effort. How much work is there, even if all of it is straightforward?
• Risk. What could go wrong: fragile code, external dependencies, unclear requirements?

Because points are relative to a team’s own history, they should never be compared across teams. One team’s 5 is another team’s 2, and both are right. For the same reason, converting points back into hours quietly destroys their value, a trade-off we unpack in story points vs hours.

Story points are not the only valid approach. Some teams size with T-shirts, and some skip estimation entirely. What matters is a scale the whole team understands the same way.

Why planning poker uses Fibonacci numbers

The classic planning poker deck follows the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 21, and beyond. Some decks extend it with 40 and 100 for very large items.

The growing gaps are the point. The difference between a 2 and a 3 is something a team can genuinely reason about; the difference between a 34 and a 35 is not. As work gets bigger, uncertainty grows with it, so the scale offers fewer, wider choices and discourages false precision. A big story is a 13 or a 21, never a 17.

One More Point’s Fibonacci deck runs from 0 to 21, plus a ? card for "I can’t estimate this yet." If a story feels bigger than 21, that is usually a sign to split it before estimating.

Fibonacci is the default, but not the only option. There is also a T-shirt sizing deck (XXS to XXL) for roadmap-level sizing, a Power of 2 deck (1, 2, 4, 8, and up), and fully custom decks where you define your own values.

An example Scrum Poker session

Here is how a typical round plays out. A team of five is estimating this story: "As a returning user, I want to reset my password so that I can regain access to my account."

The Product Owner reads the story and its acceptance criteria. Everyone picks a card in private, and the reveal shows a wide spread: 2, 3, 5, 5, 13.

The facilitator asks the outliers to explain. The developer who voted 2 points out that the codebase already has a transactional email service, so sending the reset link is mostly wiring. The QA engineer who voted 13 lists what worries them: expired tokens, reused tokens, accounts locked after failed attempts, and what happens to a user who signed up with Google and has no password at all.

That last question turns out to matter. Nobody had decided how social-login accounts should behave, and the acceptance criteria say nothing about it. The Product Owner clarifies on the spot: social-login users get a message pointing them to their provider, and that path becomes its own acceptance criterion.

The team votes again: 5, 5, 8, 5, 8. After a short exchange, the 8s agree the token-handling risk is now understood, and the team records a 5. Fifteen minutes of discussion surfaced a missing requirement that would otherwise have appeared mid-sprint as a blocked ticket.

Who should take part in Scrum Poker?

The short answer: the people who will do the work, plus the people who understand what the work is for.

• Developers. They build the story, so their estimates carry the most weight. Every developer votes, not just the senior ones.
• QA and testers. Testing effort is part of the size, and QA often spots the edge cases everyone else missed, as in the example above.
• Product Owner. Presents each story, answers questions, and clarifies acceptance criteria. The PO usually does not vote: they own what to build, while the team owns how big it is. More in the Product Owner’s role in planning poker.
• Scrum Master or facilitator. Keeps the session moving, time-boxes discussion, and makes sure quiet voices are heard.
• Designers and other contributors. Anyone whose work is part of delivering the story should estimate it too.

In One More Point, rooms can label participants as Dev, QA, or PO, and anyone can join as a spectator, which is useful for stakeholders who want to watch without affecting the vote. Up to 50 people can join one room, and there are extra tips for planning poker with large teams.

Scrum Poker for remote and hybrid teams

Estimation is one of the ceremonies that suffers most when a team goes remote. On a video call, the first number spoken anchors everyone, people talk over each other, and half the team quietly disengages.

An online scrum poker room fixes the structure of the problem rather than the symptoms. Everyone votes at the same time and in private, whether they sit in the office, at home, or nine time zones away:

• Share one link. Teammates join by link, room code, or QR code from any device (phone, tablet, or desktop) with nothing to install.
• Real-time sync. Voting status updates live for everyone as cards are cast.
• Hidden votes, single reveal. Nobody sees a number until the host reveals them together, or auto-reveal flips them when the last vote is in.
• Drop-off protection. Refresh the page or lose Wi-Fi and you rejoin automatically with your vote intact.
• A shared record. Round history is stored in the room and exportable as a CSV for your sprint notes.

Hybrid meetings, with half the team in a room and half dialled in, benefit even more, because a shared poker room puts everyone on equal footing. There is more on this in planning poker for remote teams and our tips for async sprint planning across time zones.

The benefits of Scrum Poker

Scrum Poker has stayed popular since the early 2000s because it fixes several problems at once:

• Reduces anchoring bias. Independent votes mean no one is pulled toward the first number spoken.
• Gets everyone involved. Every voter must commit to a card, so quiet team members estimate instead of deferring.
• Reveals hidden assumptions. A wide spread is a signal that people understand the story differently.
• Builds shared understanding. The discussion matters more than the number it produces.
• Supports backlog refinement. Quick rounds size upcoming work before sprint planning.
• Creates useful conversations. High and low voters explaining themselves surfaces risks early.
• Flags oversized stories. When estimates hit the top of the deck, the story needs splitting.
• Makes remote estimation practical. Simultaneous private voting works the same from anywhere.
• Stops the loudest voice from deciding. Seniority and volume have no effect on hidden cards.

One honest caveat: Scrum Poker does not guarantee accurate estimates. Nothing does. It produces estimates the team actually reasoned about, which is the best available starting point.

Common Scrum Poker mistakes

Most bad Scrum Poker experiences trace back to a handful of habits. Watch for these:

• Treating points as hours. The moment points map to time, people game them and comparisons break.
• Letting senior people vote first. Even informally ("I’d say it’s a 5, but you decide"), it anchors the room.
• Revealing votes early. Partial reveals leak information and bias whoever has not voted yet.
• Estimating unclear stories. If nobody can answer basic questions, refine the story instead; that is what the ? card is for.
• Over-debating small gaps. A 5-versus-8 disagreement rarely deserves ten minutes. Pick one and move on.
• Using estimates as performance metrics. Measuring people by points delivered corrupts every future estimate.
• Comparing velocity across teams. Each team’s scale is its own; cross-team point comparisons are meaningless.
• Including people who don’t know the work. Votes without delivery context add noise, not signal.
• Skipping discussion on wide spreads. The spread is the valuable part; recording an average wastes it.
• Estimating epics as one story. If it maxes out the deck, split the story first.

We dissect these habits, and how to break them, in common planning poker mistakes.

Scrum Poker best practices

A few habits make every session faster and the estimates more useful:

• Refine before you estimate. Stories should meet a basic definition of ready; see effective backlog refinement.
• Keep acceptance criteria visible. Set the story title in the room so everyone estimates the same thing.
• Use a reference story. Anchor the scale on a well-understood past story: "the export button was a 3."
• Time-box discussion. Two or three minutes per disagreement, then re-vote.
• Ask the outliers first. The highest and lowest votes carry the most information.
• Re-vote after real clarification. New information deserves a fresh, blind round.
• Split anything that hits the top of the deck. A 21 is a request to decompose, not a commitment.
• Keep it psychologically safe. A "wrong" estimate must cost nothing, or people stop voting honestly.
• Vote independently, always. No thinking out loud during the voting phase.
• Stay on one deck. Switching scales mid-project resets everyone’s calibration.
• Record and move on. Capture the number, note any follow-ups, and go to the next story.

And when the team truly cannot agree, there are good ways to break an estimation deadlock that do not involve averaging two numbers nobody believes.