What is Planning Poker? The Complete Guide to Agile Estimation

Planning poker is one of the most effective techniques agile teams use to estimate work. If you've ever struggled with wildly inaccurate sprint forecasts or endless estimation debates, planning poker offers a structured solution that leverages the wisdom of your entire team.

In this comprehensive guide, we'll explain what planning poker is, how it works, and why teams across the world rely on it for more accurate agile estimation.

---

Key Takeaways

• Planning poker is a consensus-based estimation technique where team members independently vote on story complexity using numbered cards
• Created by James Grenning in 2002 and popularized by Mike Cohn, it eliminates anchoring bias and encourages team discussion
• The process involves presenting a story, independent voting, revealing cards simultaneously, discussing outliers, and re-voting until consensus
• Most teams use Fibonacci-like sequences (1, 2, 3, 5, 8, 13, 21) because the gaps reflect increasing uncertainty
• Remote teams can run effective planning poker sessions using digital tools like ScrumDeck
• Common mistakes include estimating in hours instead of relative effort and rushing discussions

---

What is Planning Poker?

Planning poker, also called scrum poker or agile estimation poker, is a gamified consensus-based technique for estimating the relative effort of user stories, features, or tasks in agile development.

Here's the core concept: instead of one person dictating estimates or the team debating endlessly, each participant privately selects a card representing their estimate. Everyone reveals their cards simultaneously. This simple mechanic eliminates the social dynamics that typically derail estimation sessions.

The Origin of Planning Poker

James Grenning invented planning poker in 2002 while working with an agile team that struggled with traditional estimation approaches. He observed that when senior developers spoke first, junior team members simply deferred to their judgment, even when they had valuable insights to share.

Grenning's solution was elegant: force everyone to commit to an estimate before seeing what others think.

Mike Cohn later popularized the technique in his influential book Agile Estimating and Planning (2005), which helped spread planning poker throughout the agile community. Today, it's a standard practice in Scrum, Kanban, and hybrid agile methodologies.

How Planning Poker Differs from Traditional Estimation

Traditional software estimation often falls into predictable traps:

• Expert-driven estimates: A senior developer provides numbers that everyone else accepts without question
• Committee averaging: Teams negotiate to a middle ground that satisfies no one and reflects no one's actual thinking
• Pressure-based estimates: Management expectations drive numbers rather than technical reality

Planning poker explained simply: it's a structured process designed to surface diverse perspectives, encourage healthy debate, and arrive at estimates the whole team believes in.

---

Why Use Planning Poker?

The planning poker process delivers several measurable benefits that make estimation more accurate and team-friendly.

1. Eliminates Anchoring Bias

Anchoring bias occurs when the first number mentioned influences all subsequent estimates. In a typical meeting, if a tech lead says "this looks like a two-week task," other team members unconsciously adjust their thinking around that anchor, even if their gut told them something different.

Planning poker eliminates anchoring by requiring simultaneous card reveals. No one knows what others think until everyone has committed.

2. Surfaces Hidden Knowledge

Your team members possess different knowledge:

• The backend developer knows about a legacy system quirk
• The QA engineer remembers a similar feature that caused regression issues
• The junior developer recently read documentation that others missed

When estimates diverge significantly, say, one person plays a 3 and another plays a 13, that's a signal to discuss. Often these conversations reveal assumptions, risks, or dependencies that would otherwise surface mid-sprint as unpleasant surprises.

3. Creates Psychological Safety

Junior team members often hesitate to contradict senior colleagues publicly. Planning poker's simultaneous reveal creates a safe space for everyone's genuine assessment.

When a junior developer's 13 sits next to a senior developer's 5, the conversation shifts from "correcting" the junior to genuinely exploring why they see the task differently.

4. Builds Shared Understanding

The discussion phase of planning poker forces the team to articulate assumptions and align on scope. By the time you reach consensus, everyone understands:

• What the story actually requires
• What's explicitly out of scope
• Which risks or dependencies exist
• How this story relates to previous work

This shared understanding reduces mid-sprint surprises and scope creep.

5. Improves Velocity Predictability

Teams that use planning poker consistently report more stable velocity over time. When estimates reflect genuine team consensus rather than one person's optimism, sprint forecasts become more reliable.

---

How Planning Poker Works: Step-by-Step Process

Ready to run your first planning poker session? Here's the complete planning poker process broken down into clear steps.

What You Need

• Cards: Physical decks or a digital planning poker tool
• Backlog: Prioritized user stories or tasks to estimate
• Facilitator: Usually the Scrum Master or Product Owner
• Timer: To keep discussions focused (optional but recommended)

Step 1: Present the Story

The Product Owner or facilitator reads the user story aloud, including:

• The user story itself (who, what, why)
• Acceptance criteria
• Any relevant context or constraints

Team members ask clarifying questions. This isn't the time for debate, just ensure everyone understands what they're estimating.

Tip: Keep story presentations under 2-3 minutes. If a story requires extensive explanation, it may need to be broken down further.

Step 2: Individual Estimation

Each team member privately selects a card representing their estimate. No discussion, no peeking, no hints.

This private commitment is crucial. The moment someone says "I'm thinking around a 5," you've introduced anchoring bias.

Step 3: Simultaneous Reveal

On the facilitator's count, everyone reveals their cards at the same time. Digital tools handle this automatically, cards flip simultaneously so no one can change their vote.

Step 4: Discuss the Outliers

If estimates align closely (say, three 5s and two 8s), you can quickly converge on a number.

When estimates diverge significantly, the magic happens. The facilitator asks the highest and lowest voters to explain their thinking:

• "Sarah, you played a 13. What are you seeing that makes this complex?"
• "Tom, you played a 3. Walk us through your approach."

These discussions often reveal:

• Missing requirements or acceptance criteria
• Technical risks one person identified
• Different assumptions about implementation approach
• Scope ambiguity that needs clarification

Important: This is a discussion, not a debate. The goal is understanding, not winning.

Step 5: Re-Vote

After discussion, the team votes again. Usually estimates converge significantly on the second round as shared understanding improves.

If consensus remains elusive after two or three rounds, common approaches include:

• Taking the higher estimate (conservative)
• Taking the average (moderate)
• Flagging the story as needing further breakdown (recommended for large variance)

Step 6: Record and Move On

Record the final estimate and move to the next story. Avoid relitigating previous estimates, trust your process.

---

Ready to streamline your planning poker sessions? ScrumDeck makes agile estimation poker fast and frustration-free. Real-time voting, automatic consensus detection, and seamless backlog integration, try it free with your team.

---

Card Values Explained

Not all planning poker decks are created equal. The numbers on your cards encode assumptions about uncertainty and precision.

Fibonacci Sequence (Most Popular)

Cards: 0, 1, 2, 3, 5, 8, 13, 21, 34, (55, 89)

The Fibonacci sequence is the most common choice for agile estimation poker. The key insight: gaps between numbers grow larger as values increase.

Why this works:

• Small stories (1-3 points): You have high confidence, so fine-grained distinctions make sense
• Medium stories (5-13 points): Increasing uncertainty means less precision is appropriate
• Large stories (21+): These should probably be broken down anyway; large gaps discourage false precision

When someone debates whether a story is a 34 or a 55, that's a signal the story is too big to estimate meaningfully.

Modified Fibonacci

Cards: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100

Some teams prefer modified sequences that:

• Include ½ for trivial tasks
• Use rounder numbers at the top (20 instead of 21, 40 instead of 34)
• Add 100 to flag "this is way too big"

T-Shirt Sizes

Cards: XS, S, M, L, XL, XXL

T-shirt sizing works well for:

• Early-stage estimation during roadmap planning
• Non-technical stakeholders who find numbers intimidating
• Teams new to relative estimation

The downside: T-shirt sizes don't translate directly to velocity calculations, so many teams convert to numbers eventually.

Powers of 2

Cards: 1, 2, 4, 8, 16, 32

Some teams prefer powers of 2 because:

• The doubling relationship is intuitive
• Fewer options speed up voting
• Clear relative comparisons (an 8 is exactly twice a 4)

Special Cards

Most decks include special cards beyond numbers:

| Card | Meaning | |------|---------| | ? | "I don't have enough information to estimate" | | ∞ | "This is infinitely complex or impossible" | | ☕ | "I need a break" (useful for long sessions) | | 0 | "This is already done or trivially simple" |

---

Common Mistakes to Avoid

Even experienced teams fall into these planning poker traps.

Mistake 1: Estimating Hours Instead of Effort

Story points measure relative complexity, not time. A 5-point story isn't "5 hours of work", it's "about as complex as other things we've called 5 points."

Estimating in hours invites pressure to commit to deadlines. Relative estimation acknowledges uncertainty while still enabling forecasting.

Mistake 2: Letting One Voice Dominate

If the same person always explains their estimate first after reveals, anchoring bias creeps back in. Rotate who speaks first, and specifically invite quieter team members to share.

Mistake 3: Rushing to Consensus

The value of planning poker lies in discussion. If your team consistently agrees on the first vote, either:

• Your stories are extremely well-defined (great!)
• People are conforming rather than thinking independently (not great)

Genuine disagreement is healthy. Embrace it.

Mistake 4: Re-Estimating Mid-Sprint

Once a story enters the sprint, its estimate is locked. Changing estimates mid-sprint corrupts your velocity data and creates perverse incentives.

If a story proves larger than expected, that's valuable information, but record it in your retrospective, not by revising history.

Mistake 5: Estimating for Individuals

"Well, if Sarah does it, it's a 3, but if I do it, it's an 8."

Story points should reflect team capacity, not individual speed. Estimate as if a reasonably capable team member would handle it. Over time, velocity naturally accounts for skill variance.

Mistake 6: Marathon Sessions

Estimation fatigue is real. After 60-90 minutes, quality degrades significantly. Better to estimate fewer stories well than blow through the backlog with declining attention.

---

Planning Poker for Remote Teams

Remote and distributed teams can run effective planning poker sessions with the right approach.

Synchronous Remote Sessions

For real-time estimation with video conferencing:

1. Use a digital planning poker tool: Physical cards don't work when you can't see each other's hands
2. Enable video: Facial expressions and body language add context to discussions
3. Assign a facilitator: Even more important remotely to manage turn-taking
4. Use breakout rooms: For larger teams, estimate in smaller groups then reconcile

Asynchronous Estimation

Some distributed teams estimate asynchronously:

1. Product Owner posts stories with context
2. Team members vote within a time window (24-48 hours)
3. Facilitator identifies stories with high variance
4. Synchronous discussion for divergent estimates only

This hybrid approach respects time zones while preserving the benefits of discussion where it matters most.

Remote Planning Poker Best Practices

• Check everyone has voted before revealing: Digital tools handle this automatically
• Build in extra discussion time: Remote communication is slower
• Record decisions: Capture reasoning so absent team members can catch up
• Keep sessions shorter: Video call fatigue is real; aim for 45-60 minutes max

---

Tools for Planning Poker

While planning poker can be run with physical cards, digital tools offer significant advantages, especially for remote or hybrid teams.

What to Look for in a Planning Poker Tool

Essential features:

• Simultaneous card reveal (prevents anchoring)
• Automatic consensus detection
• Integration with your backlog tool (Jira, Linear, etc.)
• Mobile-friendly for hybrid meetings

Nice-to-have features:

• Timer for discussions
• History of past estimates
• Velocity tracking
• Custom card decks

ScrumDeck: Planning Poker Built for Modern Teams

ScrumDeck combines powerful planning poker with seamless backlog management. Teams love it because:

• Instant sessions: Share a link; no accounts required for participants
• Smart consensus: Automatically detects agreement and suggests averages
• Backlog sync: Estimates flow directly to Jira, Linear, or your CSV export
• Beautiful experience: A planning poker tool your team actually enjoys using

Whether you're co-located, remote, or hybrid, ScrumDeck makes agile estimation poker fast and focused.

---

Frequently Asked Questions

How long should a planning poker session last?

Plan for 60-90 minutes maximum. Estimation fatigue sets in quickly, and quality degrades in longer sessions. If your backlog requires more time, schedule multiple sessions rather than one marathon.

How many stories can a team estimate per hour?

Experienced teams typically estimate 8-15 stories per hour, depending on complexity and discussion needs. New teams or complex domains may only manage 4-6. Focus on quality over quantity.

What if the team can't reach consensus?

After two or three voting rounds, if significant disagreement persists:

1. Check if the story needs clarification or breakdown
2. Consider taking the higher estimate (conservative approach)
3. Note the uncertainty and plan a spike to reduce it

Forced consensus isn't real consensus. Disagreement often signals legitimate uncertainty.

Should the Product Owner vote in planning poker?

It depends on your team. Some include the PO to leverage their domain knowledge. Others exclude the PO to prevent their presence from influencing technical estimates. The key is consistency, pick an approach and stick with it.

Can planning poker work for non-development tasks?

Absolutely. Teams use planning poker for:

• Content creation and marketing tasks
• Design work
• Research spikes
• Infrastructure and DevOps work

Any work that benefits from relative estimation and team input can use planning poker.

What's the difference between planning poker and team estimation game?

Both are consensus-based estimation techniques. Planning poker estimates stories one at a time with discussion. Team estimation game (also called affinity estimation) places multiple stories simultaneously on a relative scale. Team estimation game is faster for large backlogs; planning poker provides deeper discussion per story.

---

Start Running Better Planning Poker Sessions

Planning poker transforms estimation from a solo guessing game into a collaborative team exercise. By eliminating anchoring bias, surfacing hidden knowledge, and building shared understanding, it produces estimates your whole team believes in.

The key ingredients:

• Simultaneous reveals to prevent bias
• Genuine discussion of divergent estimates
• Relative sizing rather than hour-counting
• Consistent practice to calibrate as a team

Whether you're new to agile estimation poker or looking to improve your existing practice, the principles remain the same: trust your team's collective intelligence, embrace healthy disagreement, and let the process surface what matters.

---

Ready to transform your estimation sessions? Try ScrumDeck free and see why hundreds of agile teams rely on it for fast, focused planning poker. No credit card required, get your team estimating in minutes.