Estimation is one of the most consistently difficult parts of software development. Ask five engineers how long a feature will take and you'll get five different answers — shaped by different assumptions, different risk tolerances, and, crucially, by what they heard the others say first. That last part is the killer. It's called anchoring bias, and it makes group estimation almost useless by default.
Planning poker was designed specifically to solve this problem. It's been around since 2002, used by teams at every scale from two-person startups to engineering departments with hundreds of developers — and it works. Here's why, and how to run a session that produces reliable estimates.
How Planning Poker Works
Each team member gets a deck of cards. The most common deck uses Fibonacci numbers: 1, 2, 3, 5, 8, 13, 21, and usually a question mark and a coffee cup. The Fibonacci sequence is intentional — the gaps between numbers grow as complexity increases, reflecting the reality that larger work items carry more uncertainty.
The facilitator reads a user story. Everyone thinks independently, then simultaneously reveals their card. Nobody sees anyone else's number until the reveal. This is the critical mechanism: simultaneous reveal eliminates anchoring. The senior engineer's opinion doesn't shade the junior developer's estimate. Everyone commits to their honest assessment before seeing the group.
When estimates diverge significantly — a 3 and a 13 on the same story, for instance — the team discusses. The person who estimated high explains their concerns. The person who estimated low explains what assumptions they made. The team often discovers that they're estimating different things: one person is thinking about the API work, another is thinking about the API work plus the UI plus the tests plus the deployment. The discussion is where the real value is.
Why It Works
The research on group estimation is clear: unstructured group discussions are dominated by whoever speaks first, most confidently, or with the most seniority. Planning poker short-circuits all three. By requiring simultaneous commitment before discussion, it ensures that every voice contributes independently.
The second reason it works is that it makes disagreement visible. In a regular meeting, people nod along even when they privately think an estimate is way off. Planning poker forces the outliers into the open, which is exactly where you want them. An unexplained 13 next to three 3s is a signal that someone knows something the group doesn't.
Running an Effective Session
Before the session
The most important preparation is the backlog. Stories should be crisp enough to estimate — a single, well-defined behaviour that a developer can reason about. If a story is too vague to discuss for more than two minutes, it probably needs to be split or refined before the session.
During the session
Keep rounds focused. Read the story, answer clarifying questions, reveal, discuss outliers, re-estimate if needed, lock the point value, move on. Aim for three to five minutes per story. If a story generates more than ten minutes of debate, that's a signal to defer it for refinement rather than forcing a false consensus.
Modern tools make this significantly smoother. ScrumTool's planning poker handles hidden card selection and simultaneous reveal in real time, whether the team is in the same room or distributed across five timezones. Consensus is detected automatically when everyone picks the same value, so the facilitator doesn't have to watch for it manually.
After the session
Log the estimates. Track velocity — how many points the team completes per sprint versus how many they planned. Over time, this data makes future planning sessions more accurate. Teams that track velocity for six months can predict sprint capacity within ten percent.
Common Mistakes to Avoid
- Averaging estimates instead of discussing. If the team votes 2, 3, 8, 13, averaging them to 6 tells you nothing. The outliers are the signal — talk to them.
- Letting one person anchor the group. Even well-intentioned facilitators do this. Keep the reveal simultaneous.
- Estimating in hours. Story points aren't hours. They're a relative measure of complexity and effort. The moment you map points to hours, you've reintroduced the pressure to be "right" that planning poker is designed to remove.
- Rushing consensus. If the team can't agree after two rounds, defer the story. A forced estimate is worse than no estimate.
Which Deck Should You Use?
Fibonacci is the most common and works for most teams. T-shirt sizes (XS, S, M, L, XL) are better for teams that struggle to reason about relative numbers — they're more intuitive for non-technical stakeholders in mixed sessions. Powers of 2 (1, 2, 4, 8, 16) work well for teams that prefer exponential rather than Fibonacci spacing.
ScrumTool supports all three plus fully custom decks. Pick what works for your team and stay consistent — switching decks mid-project makes velocity data meaningless.
The Bottom Line
Planning poker isn't a silver bullet for estimation accuracy. What it is, reliably, is a mechanism for surface disagreement early, making implicit assumptions explicit, and arriving at a number the team actually believes in. Those three things are worth an enormous amount in sprint planning.
Run your first session with ScrumTool — it's free to start, and the simultaneous reveal works seamlessly for remote teams.