What Is Scrum Poker? Estimating Without the Awkward Silence

Scrum Poker — also called Planning Poker — is the game teams play to estimate how big a piece of work is, without everyone just copying the loudest person in the room. It's a little weird when you first see it, and honestly it's one of my favourite ceremonies. Let me walk you through it.

The setup

Everyone on the team gets a hand of cards. Each card has a number on it — usually the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 21, and maybe a "?" for "I have genuinely no idea" and a coffee cup for "break time."

The Product Owner (or whoever's running the session) reads out a piece of work from the backlog — a user story, a ticket, whatever. Then the team discusses it briefly: what's involved, what could go wrong, any unknowns.

How a round goes

1. Someone reads the story out loud.
2. The team chats for a minute or two — clarifying questions, risks, assumptions.
3. Everyone secretly picks a card and places it face down. No talking about numbers yet.
4. On the count of three, everyone flips their card at the same time.
5. If everyone picked the same number — great, that's the estimate. Moving on.
6. If the numbers are all over the place (a 2 and a 13, say), the outliers explain why. The person who said 2 hears why someone thinks it's a 13. Then you re-vote.

That flip is the whole magic of the game. Nobody gets to anchor the conversation with "oh this is easy, it's a 2" before anyone else has thought. Everyone commits to a number independently, then the discussion happens after — which means the discussion is about the work, not about egos.

Why Fibonacci?

Good question, and the answer is more practical than mystical. As work gets bigger, our ability to tell it apart gets worse. The difference between a 1 and a 2 is easy to feel. The difference between a 21 and a 22? Nobody can actually feel that. So the scale grows: 1, 2, 3, 5, 8, 13, 21. The gaps widen as the numbers grow, which matches how our brains actually estimate — we're precise on small things and fuzzy on big ones.

It also stops the "but a 6 is bigger than a 5" arguments. With Fibonacci, there is no 6. You're either a 5 or an 8, and the jump forces a real conversation.

Points, not hours

Here's the mental shift that trips people up: the numbers aren't hours. A "5" is not "5 hours." It's "about twice as big as a 2, whatever that means for us." The team builds a shared sense over time — "oh, a typical 5 is a new API endpoint with tests." That shared scale is the real asset, and it survives team changes and tech changes better than hour estimates ever do.

And because they're relative, you can't be accused of being slow. A 5 for us might be a 3 for a bigger team — and that's fine, because velocity (the points we complete per sprint) is our number, not a benchmark against anyone else.

The real example

My favourite poker moment: we had a ticket that the senior dev swore was a 2 — "it's just a config change." One person on the team quietly played a 13. When asked why, they said "config change, sure, but it touches the billing service, and the last time anyone touched the billing service we were down for a day." Silence. We re-voted. It came out an 8. The quiet person had context nobody else had, and the game surfaced it before we committed. That's the whole point.

Quick answers

Who plays Scrum Poker? The people doing the work — the developers. The Product Owner answers questions but doesn't normally vote (they have opinions, but the estimate is the doers').

How long does it take? A well-run session estimates maybe 5-10 stories an hour. If a story takes forever to estimate, it's usually too big and should be split.

Do we always have to agree? You aim for consensus-ish. Most teams accept it when the range tightens to within a Fibonacci step. Perfect agreement on every story isn't the goal.

Tip: Remote team estimating? Running poker over a shared screen with everyone revealing in a group chat works, but dedicated planning poker tools make it much smoother — and a ClockHive tab in the corner keeps you honest about whether the session lands in everyone's timezone.