Planning Poker Cards Explained: What Each Number Means

Ever wondered why planning poker numbers jump from 5 to 8, skipping 6 and 7? Or what that coffee cup card actually means? You're not alone.

Understanding each card's purpose transforms estimation from guesswork into a calibrated team exercise. This guide decodes every card in a standard planning poker deck—from 0 to 100—explaining what each represents, when to use it, and how to avoid common pitfalls.

What Are Planning Poker Cards?

Planning poker cards are a consensus-based estimation tool used by agile teams to gauge the effort required for user stories or tasks. Each team member holds an identical deck with values following a modified Fibonacci sequence: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, plus special cards like ? (unsure) and ☕ (coffee/break).

These cards don't measure time—they represent story points, a relative measure combining complexity, effort, and uncertainty.

Why These Specific Numbers?

Planning poker uses the Fibonacci sequence instead of a simple 1-10 scale for three critical reasons:

The Fibonacci Foundation

In the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, 55...), each number equals the sum of the two preceding it. The gaps grow larger as numbers increase—which perfectly mirrors estimation reality:

1. Reflects increasing uncertainty: Larger tasks are harder to estimate accurately. The jump from 1 to 2 is manageable, but 20 to 40 acknowledges that big tasks have exponentially more unknowns.

2. Prevents false precision: Cards for 6, 7, 8, and 9 create an illusion of accuracy that doesn't exist. Can you truly distinguish a "7-point" from an "8-point" story? The honest answer is no.

3. Encourages debate: When forced to choose between 5 and 8 (no 6 available), teams discuss whether the task is genuinely medium or trending complex. This conversation matters more than the number itself.

Modified for Practical Use

Most decks use a modified Fibonacci sequence, rounding larger numbers (20 instead of 21, 40 instead of 34, 100 instead of 89) to avoid false precision on big estimates.

The Complete Planning Poker Deck Explained

Let's break down what each card value means and when to use it.

0 - Zero Effort Tasks

What it represents: Virtually no effort—the work's already done or takes seconds.

When to use it:

• Work complete, just needs verification
• Configuration changes taking seconds
• Simple documentation updates with no research

Example: "Update the copyright year in the footer from 2024 to 2025."

Common mistake: Using 0 for "quick" tasks that still require thought. If problem-solving is involved, it's at least ½.

½ - Minimal Effort

What it represents: The smallest unit of meaningful work. Straightforward, no complexity.

When to use it:

• Simple text changes requiring minimal context
• Adding a single line of logging
• Minor CSS tweaks with clear specs
• Renaming a variable across a few files

Example: "Change button text from 'Submit' to 'Send Message' on the contact form."

Common mistake: Underestimating because it seems "simple." If it requires opening multiple files or understanding business logic, it's a 1.

1 - Simple, Well-Defined Tasks

What it represents: Small tasks with clear requirements and no expected complications.

When to use it:

• Adding a form field with existing validation patterns
• Writing simple unit tests for straightforward functionality
• Implementing minor features with clear specs
• Fixing typo bugs with obvious solutions

Example: "Add email validation to the registration form." The validation library exists, you know the pattern—just apply existing code to a new field.

Key indicator: If you can describe the implementation in one sentence, it's a 1.

2 - Straightforward with Minor Complexity

What it represents: Still simple but requires more thought or touches multiple areas.

When to use it:

• Features coordinating 2-3 files
• Bug fixes needing investigation but with clear scope
• Small refactoring with minimal risk
• New components with simple props

Example: "Add a character counter to the comment textarea." Requires state management, UI updates, tests, and accessibility checks—more than 1, but straightforward.

Common mistake: Voting 1 because the description is short. Description length ≠ complexity.

3 - Moderate Complexity

What it represents: Tasks with complexity, multiple steps, or dependencies. May require coordination or system integration.

When to use it:

• Features requiring database schema changes
• Third-party API integrations with good documentation
• Medium-sized refactoring affecting several components
• Bug fixes requiring moderate investigation

Example: "Implement user profile image upload with thumbnail generation." File upload handling, validation, storage integration, database updates, and UI changes across multiple views.

Key indicator: If you're mentally listing 4-5 steps to complete it, it's a 3.

5 - Significant Effort Required

What it represents: Notable complexity, multiple moving parts, or uncertainty about implementation.

When to use it:

• Complete features with front-end and back-end components
• Complex integrations with moderate documentation
• Performance optimization requiring profiling and testing
• Security implementations requiring research

Example: "Add real-time notifications using WebSockets." WebSocket infrastructure, connection management, reconnection handling, UI updates, state persistence, and thorough testing.

Common mistake: Splitting 5-point stories too early. A cohesive 5-pointer often delivers more value than three disconnected 2-pointers.

8 - Substantial Complexity

What it represents: Large features with significant complexity, multiple unknowns, or cross-cutting concerns. Typically the maximum size for a sprint.

When to use it:

• Major features spanning multiple subsystems
• Complex data migrations with business logic
• New architectural patterns
• Integration with poorly documented third-party systems

Example: "Implement multi-factor authentication across the platform." MFA research, auth provider integration, login flow updates, backup codes, session management changes, security testing, and user migration strategy.

Red flag: Frequently voting 8 signals stories need better breakdown. 8s should be rare in well-groomed backlogs.

13 - Extremely Complex

What it represents: Very large features with high complexity and uncertainty. Too big for a single sprint—needs breakdown.

When to use it:

• Initial estimation during backlog grooming before breakdown
• Exploratory spikes to understand complexity
• Major architectural changes affecting the entire system

Example (before breakdown): "Add payment processing with multiple providers, subscription management, and invoicing." Split this into "Integrate Stripe payment gateway" (5), "Build subscription management UI" (5), "Implement invoice generation" (3), etc.

Best practice: A 13 vote signals "break this down," not "take this into the sprint."

20 - Epic-Level Work

What it represents: Work requiring decomposition. Rarely used for sprint planning—appears during initial backlog estimation.

When to use it:

• Entire features becoming multiple user stories
• System redesigns
• Platform migrations
• Initial estimation of vague requirements

Example: "Redesign the entire checkout experience." Needs breakdown into research, design, implementation steps, testing, and gradual rollout.

Important: Voting 20 during sprint planning? Stop and break it down first.

40 - Major Initiatives

What it represents: Multi-sprint initiatives or entire projects. Almost exclusively for high-level roadmap planning, not sprint work.

When to use it:

• Quarterly initiatives
• Major product features becoming epics
• Rough estimates for long-term planning

Example: "Build a mobile app version of the platform." Months of work requiring extensive planning and breakdown.

Reality check: Rarely used once you have a well-groomed backlog.

100 - Massive Projects

What it represents: Initiatives spanning multiple teams or quarters. Essentially "this is enormous" during very early planning.

When to use it:

• Annual strategic initiatives
• Complete platform rewrites
• New product lines

Example: "Build an enterprise version with SSO, audit logging, custom branding, and admin dashboards."

Practical note: Voting 100 means you lack enough information to estimate meaningfully. Consider a spike story to research and break it down.

Special Cards Explained

? - Unsure / Need More Information

What it represents: Insufficient information or unclear requirements.

When to use it:

• Unclear requirements or acceptance criteria
• Technical unknowns needing investigation
• Missing critical information

What happens next: Stop and discuss. Don't average it out. Clarify requirements or create a spike story to investigate before estimating.

Example: "Improve performance" without specifics. What needs improvement? By how much? What's the baseline? Without answers, ? is correct.

Pro tip: ? votes highlight gaps in story writing—they're valuable data.

☕ - Coffee / Need a Break

What it represents: The team needs a break. Estimation sessions are mentally taxing.

When to use it:

• After 90+ minutes of estimating
• Team clearly losing focus
• Discussions becoming unproductive

What happens next: Take 10-15 minutes. Fresh minds make better estimates.

Important: Not a joke card. Mental fatigue kills estimation accuracy. Use it.

Common Estimation Scenarios and Solutions

Scenario 1: Wide Spread of Votes

Situation: Votes range from 2 to 8 for one story.

What it means: Significant understanding gap. The 2 voter sees simplicity; the 8 voter sees hidden complexity.

Solution: Highest and lowest voters explain their reasoning. Often, the high voter knows about technical debt or edge cases others missed. This discussion is planning poker's most valuable part. For more on handling disagreements, see our dedicated guide.

Scenario 2: Everything is 5 or 8

Situation: Team rarely votes 1, 2, or 3.

What it means: Stories are too large, or your baseline is miscalibrated.

Solution: Establish concrete reference stories. Pick completed stories everyone agrees were a 1, a 3, and a 5. Use these as anchors for future estimates.

Scenario 3: "Just Average the Votes"

Situation: Votes are 5, 5, 5, 8—someone suggests using 6.

What it means: Bypassing planning poker's purpose: consensus, not averaging.

Solution: Don't compromise to non-Fibonacci numbers. Have the 8 voter explain their concern. They'll either convince others it's an 8, or be convinced it's a 5. Discussion matters more than splitting differences.

Using Planning Poker Effectively

Best Practices

1. Estimate relative to each other, not absolute time: Don't think "8 hours = 8 points." Think "twice as complex as that 3-pointer we did last sprint."

2. Use completed work as reference points: "Remember the login refactor? That was a 5. Is this more or less complex?"

3. Focus on the full definition of done: An 8 includes coding, testing, code review, documentation, and deployment—not just coding time.

4. Re-estimate if requirements change significantly: New information mid-sprint? Acknowledge the original estimate no longer applies.

5. Track estimates vs. actuals: Review which stories took longer than expected and why. This calibrates your team's estimation skill over time. Learn more about planning poker metrics.

Common Mistakes to Avoid

Mistaking story points for hours: Story points aren't hours. A 5-point story might take a senior dev 4 hours and a junior dev 12 hours—that's fine. Points measure complexity and uncertainty, not duration.

Sandbagging estimates: Consistently over-estimating to "make sprint commitments easier" defeats the purpose. Velocity adjusts, and you'll just inflate all estimates.

Estimating based on who will do the work: Assume a team member with average skill does the work. Don't estimate lower because your senior architect is available.

Ignoring the ? card: When someone votes ?, address it. Forcing estimates without clarity leads to missed commitments and frustration. Check out our guide on common planning poker mistakes.

Digital vs. Physical Planning Poker Cards

Physical cards create a tangible experience, but digital tools like Planning Poker offer advantages for remote teams:

• Remote-first collaboration: Team members join from anywhere with real-time voting
• Automatic calculation: Consensus tracking and vote statistics handled automatically
• History tracking: Review past estimates and velocity trends
• Multiple deck options: Switch between Fibonacci, T-shirt sizes, or powers of 2
• No physical logistics: No cards to lose, no need to be co-located

For teams choosing digital tools, see our comparison of the best planning poker apps.

The fundamental principles remain the same: collaborative discussion, relative estimation, and team consensus.

Conclusion

Planning poker cards aren't random numbers—each represents a deliberate level of complexity, effort, and uncertainty. The modified Fibonacci sequence forces meaningful distinctions while acknowledging that large estimates are inherently less precise.

The real power isn't in the cards themselves, but in the conversations they spark. When a developer votes 3 and a tester votes 8, that discussion uncovers assumptions, reveals technical debt, and aligns understanding before work begins.

Key takeaways:

• 0-3: Simple, well-defined work fitting easily in a sprint
• 5-8: Complex work requiring careful planning and coordination
• 13+: Work needing breakdown into smaller stories
• ? and ☕: Critical for managing uncertainty and team energy

Your team will develop its own estimation culture. A 5-point story for one team might be a 3 for another—what matters is internal consistency and continuous improvement.

For more detailed guidance on running effective sessions, see our complete guide on how to play planning poker and tips for facilitating as a Scrum Master.

Ready to start estimating? Create your first session at planning-poker.app and experience how collaborative estimation improves sprint planning and team alignment.