Planning poker is a consensus-based agile estimation technique used by Scrum teams to assign effort to user stories and backlog items. Each team member votes simultaneously using a numbered card — nobody sees anyone else's choice until everyone has committed. Then all cards flip at once.
That simultaneous reveal is the whole point. It kills anchoring bias — the tendency to anchor your estimate to the first number you hear in the room. With planning poker, the loudest person's opinion lands at the same time as everyone else's.
Where planning poker comes from
The technique was first described by James Grenning in 2002 and later popularized by Mike Cohn in his book Agile Estimating and Planning. The name is a nod to the poker mechanic: you hold your cards close, commit, then reveal. The goal isn't to win — it's to surface disagreement early and talk through it.
How a planning poker session works
The flow is simple and repeatable:
- The moderator reads a user story — usually the Product Owner presents the item and answers clarifying questions.
- Everyone picks a card privately — each team member selects a number that represents their effort estimate without showing it.
- All cards flip at once — everyone reveals simultaneously. No anchoring, no social pressure.
- Outliers explain their reasoning — the highest and lowest votes share their thinking. This is where the real value lies.
- Re-vote if needed — after discussion, the team votes again until consensus is reached.
Most stories reach consensus in one or two rounds. If a team keeps diverging after three rounds, that's usually a signal the story needs to be split or clarified — not estimated.
Why Fibonacci numbers?
Planning poker decks typically use a Fibonacci-like sequence: 1, 2, 3, 5, 8, 13, 21. The gaps grow intentionally. The difference between 8 and 13 forces a conversation. The difference between 8 and 9 doesn't.
As complexity grows, our ability to estimate precisely diminishes. Using a scale where the options get further apart reflects that reality honestly. You can't know if something will take 34 or 35 days — but you can tell if it's closer to a 13 or a 21.
The Fibonacci sequence isn't magic. It's a forcing function. It makes you commit to a rough category of size rather than pretending you can estimate with false precision.
What planning poker is not
Planning poker is not a time estimate. Story points measure relative effort and complexity, not hours. A 5-point story doesn't take 5 hours — it takes whatever it takes for your team, given your codebase, your tech debt, and your skill set.
It's also not a democracy where the majority wins. The goal is consensus through discussion, not averaging. If the outlier has spotted something everyone else missed, that outlier should change the group's mind — not get outvoted.
Planning poker vs. other estimation methods
Teams that don't use planning poker often fall into one of two traps: the expert opinion trap (the senior dev estimates everything alone) or the loudest voice trap (whoever speaks first anchors the entire discussion). Planning poker structurally prevents both.
Compared to T-shirt sizing (XS, S, M, L, XL), planning poker generates more conversation and more precise alignment. T-shirt sizing is faster and works well for high-level roadmap planning. For sprint-level estimation, planning poker wins.
How to get started
You need three things: a backlog with written user stories, a team, and a deck. Physical card decks exist, but free online planning poker tools have made remote sessions the norm. No printing, no shipping, instant setup.
Keep sessions short. Estimate 5–10 stories per session maximum. Beyond that, estimation fatigue sets in and the numbers stop meaning anything. One focused 30-minute session beats a two-hour marathon every time.