Planning Poker FAQ

Basic Concepts

What is Planning Poker?

Planning Poker is a collaborative estimation technique used in agile methodologies (mainly Scrum) where team members use cards with numerical values to estimate the complexity or effort of user stories.

The process eliminates anchoring bias by having everyone reveal their estimates simultaneously, which generates valuable discussions when there are significant differences.

Do I need physical cards for Planning Poker?

No. You have three options:

1. Online tools: Like GoSprintPlanning (free, no registration)
2. Physical cards: If your team is in-person ($10-30 USD)
3. Improvised: Paper and marker works

For remote or hybrid teams, online tools are superior because they reveal simultaneously (avoiding bias), automatically record history, and are free with no friction.

How long should a Planning Poker session last?

Short answer: 1-2 hours for a typical sprint.

Breakdown:

• 5-10 minutes per story (average)
• If you have 10-15 stories for the sprint = 90-120 minutes

Signs you’re taking too long:

• More than 15 minutes on a single story → split it
• Complete session > 3 hours → improve your backlog refinement
• Endless philosophical debates → use timeboxing (5 min max per story)

Who should participate in Planning Poker?

Should participate and vote:

• Entire development team (developers, QA, UX if they code)
• Anyone who will do the technical work

Should attend but NOT vote:

• Product Owner: Answers questions, doesn’t influence estimates
• Scrum Master: Facilitates, doesn’t estimate (unless also a developer)

Key rule: Only those who will do the work should estimate.

Story Points

What are story points?

Story points are a relative unit of measure representing the combination of:

• Complexity: How technically difficult is it?
• Effort: How much work does it involve?
• Uncertainty: How many risks or unknowns are there?

They are NOT:

• ❌ Hours of work
• ❌ Days of work
• ❌ Number of lines of code

They ARE:

• ✅ Relative comparisons: “This story is twice as complex as that one”
• ✅ Team-specific: A 5 for your team may be different than for another
• ✅ Rough estimates: They’re not precise, they’re approximate

Why use story points instead of hours?

Main reasons:

1. Hours are falsely precise

❌ "This task will take exactly 6.5 hours"
   → Ignores interruptions, unexpected bugs, learning

✅ "This task is a 5 compared to our reference"
   → Acknowledges uncertainty

2. Hours vary by person

A senior can do a task in 2 hours, a junior in 8 hours. Story points represent inherent complexity, not individual speed.

3. Hours generate micromanagement

Manager: "You said 8 hours, took 10, what happened?"
→ Defensiveness, inflation of future estimates

vs

"We estimated 5 points, was 5 points"
→ Conversation about complexity, not personal efficiency

How do I convert story points to hours?

Short answer: Don’t do it.

Long answer: If you absolutely need a time estimate (for budget, contracts), use your historical velocity:

Example:
- Team velocity: 25 points/sprint
- Sprint duration: 2 weeks = 80 hours/person (team of 5)
- Total: 400 team-hours

25 points = 400 hours
1 point ≈ 16 team-hours

But this varies wildly by story. Don't use it for individual work planning.

Better approach: Communicate in sprints, not hours:

❌ "This feature will take 160 hours"
✅ "This feature is 40 points, will take approximately 2 sprints"

What if my estimates are always wrong?

It’s normal that estimates aren’t perfect. The goal isn’t perfection, but:

1. Consistency: That a 5 is similar to other 5s
2. Continuous improvement: That estimates improve over time

Steps to improve:

Estimation retrospective (monthly):

1. Select 5 completed stories
2. Compare estimate vs actual effort
3. Ask: "What didn't we consider when estimating?"

Common:
- Underestimate testing
- Forget code review and deployment
- Ignore dependencies with other teams

Update your references:

If historically your 5s take what you thought were 8s:
→ Recalibrate what a 5 means
→ Document new examples

Fibonacci and Scales

Why Fibonacci instead of linear numbers (1, 2, 3, 4, 5)?

Fibonacci (1, 2, 3, 5, 8, 13) reflects growing uncertainty:

With linear scale:

Discussion: "Is it a 6 or a 7?"
→ 30 minutes debating insignificant differences
→ False precision

With Fibonacci:

Discussion: "Is it a 5 or an 8?"
→ Gap forces thinking in categories
→ If there's debate, there's probably something someone doesn't see

Fibonacci gaps are features, not bugs. They force valuable discussions.

Can I use my own scale?

Yes. Some teams use:

Powers of 2: 1, 2, 4, 8, 16, 32

• ✅ Mathematically simple
• ❌ Gap too large between medium values

T-Shirt Sizing: XS, S, M, L, XL

• ✅ Intuitive for non-technical people
• ❌ Difficult to calculate numerical velocity

Modified Fibonacci: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100

• ✅ Fibonacci balance with round values
• ✅ Most common in industry

Recommendation: Start with Modified Fibonacci. Change only if you have a specific reason.

Process and Best Practices

What do I do when estimates are very different?

Example: One person votes 3, another votes 13.

Process:

1. Don’t average: (3+13)/2 = 8 is not valid. Discrepancy indicates something important.

2. Ask the low estimator: “What are you assuming? What makes this simple for you?”

3. Ask the high estimator: “What risks or complexity do you see that others don’t?”

4. Common discovery:

Low estimate: "It's just adding a field to the form"
High estimate: "But do we have to validate with external API?"
                "And migrate existing data?"
                "And update reports?"

Result: Was more complex than initially appeared

5. Vote again with new information.

6. If disagreement persists:

   • Take the higher estimate (precautionary principle)
   • Or split the story to reduce uncertainty

Can I estimate during Sprint Planning?

Ideally not. Sprint Planning should use estimates already done in Backlog Refinement.

Reality: Sometimes you need to adjust or estimate new stories.

Rule of thumb:

• If you need to estimate > 3 stories in Sprint Planning → your refinement is insufficient
• Sprint Planning should be for selection and commitment, not estimation

Recommended structure:

Backlog Refinement (weekly, mid-sprint):
- Estimate stories for next 2-3 sprints
- Clarify requirements
- Split epics

Sprint Planning (start of sprint):
- Select already-estimated stories
- Adjust only if there's new information
- Define specific tasks

Tools

Do I need a special tool for remote Planning Poker?

Minimum viable: You can use chat + emojis.

"On 3, 2, 1... send your estimate"
Alice: 5️⃣
Bob: 8️⃣
Charlie: 5️⃣

Problems:

• Not simultaneous (anchoring bias)
• No automatic history
• Tedious for many stories

Better option: Dedicated tool like GoSprintPlanning.

Benefits:

• Truly simultaneous reveal
• Estimation history
• Export results
• Free, no registration

Common Problems

My manager wants to convert story points to hours for budget

Problem: Story points aren’t hours. Converting destroys their purpose.

What to do:

Option 1 - Communicate in sprints:

❌ Manager: "How many hours is this feature?"
   You: "It's 34 story points, at 16 hours per point = 544 hours"
   → Creates false expectation

✅ Manager: "When will this feature be ready?"
   You: "It's 34 points. Our velocity is 25 points/sprint.
        Will take approximately 1.5 sprints = 3 weeks"
   → Transparent and realistic

Option 2 - Use ranges:

"This feature is estimated at 34 points.
Historically, features this size take 3-5 weeks.
I can't give exact hours without destroying estimate reliability."

The Product Owner pressures for lower estimates

Symptom:

PO: "Really a 13? Can't it be an 8?"
Team: "Well... ok, 8" (under pressure)
→ Sprint fails, team looks bad

Solution:

Tactic 1 - Reject with data:

"Last time we underestimated under pressure (Story X in Sprint 5),
we failed the sprint and had to work overtime.
Our 13 estimate is based on real experience."

Tactic 2 - Scrum Master intervenes:

SM: "PO, your role is to prioritize what gets done, not how it's estimated.
     If 13 points is too much, consider splitting the story
     or moving it to a future sprint."

Tactic 3 - Split the story:

PO: "13 is a lot"
You: "What part is most important? We can do:
     - Story A: Basic functionality (5 points)
     - Story B: Edge cases and optimization (8 points)

     We do A now, B later if it has value."

Special Cases

How do I estimate bugs?

Option 1 - Estimate like stories:

Treat bugs like any other user story.

Bug: "App crashes when uploading files > 10MB"

Complexity:
- Reproduce: Simple
- Fix: Probably memory limit, config
- Testing: Need to test multiple sizes

Estimate: 3 points

Option 2 - Bug bucket:

Group small bugs in a “bucket” of points.

Sprint capacity: 25 points
- Features: 20 points
- Bug bucket: 5 points

Bucket can contain 5-10 small bugs without individual estimation.

Recommendation: Estimate large bugs (> 5 points) individually. Small bugs can go in bucket.

How do I estimate spikes (research)?

Spikes are timeboxed by nature:

❌ "Spike: Research chart library (13 points)"
   → Doesn't make sense. Not producing features.

✅ "Spike: Research chart library (4 hours timeboxed)"
   → Clear expectations

Some teams:

• Don’t estimate spikes in story points
• Count them as sprint “overhead”
• Use capacity: “25 points of features + 8 hours of spikes”

Recommendation: Timebox spikes in hours, don’t convert to story points.

Remote and Distributed Teams

Does Planning Poker work equally for remote teams?

Works better in some aspects:

Remote advantages:

• Digital tools force simultaneous reveal
• Harder anchoring bias
• Automatic history
• Shy people can participate more easily

Remote disadvantages:

• Less energy and connection
• Harder to read body language
• Zoom fatigue

Best practices for remote:

1. Camera ON: Seeing faces increases engagement
2. Frequent breaks: 5 min every 45 min
3. Dedicated tool: Not “estimation by chat”
4. Ice breaker: 5 min casual chat before starting
5. Strict timebox: Easier to digress remotely

How do I handle time zone differences?

If difference < 3 hours:

✅ Synchronous Planning Poker (live)
   - Alternate schedules to be fair (early for some, late for others)

If difference > 8 hours (e.g., US - India):

❌ Synchronous Planning Poker is unsustainable

✅ Use async estimation:
   1. PO publishes stories 24h before
   2. Each member estimates independently
   3. Tool reveals all at once
   4. Discrepancies > 5 points discussed in chat/async video
   5. Re-vote until consensus

Metrics and Improvement

How do I measure if Planning Poker is working?

Key metrics:

1. Estimation accuracy:

Accuracy Rate = Stories completed within sprint / Total stories in sprint

Goal: > 70%
Excellent: > 85%

2. Velocity stability:

Velocity Standard Deviation (last 6 sprints)

Stable: Deviation < 20% of mean
Unstable: Deviation > 30% of mean

3. Estimation time:

Average time per story

Efficient: 5-8 min/story
Inefficient: > 15 min/story

Should I track who estimates most accurately?

NO. This creates counterproductive competition.

Problems:

• People inflate estimates to “win”
• Less collaboration
• Defensive estimation

Instead:

• Celebrate complete team improvement
• Discuss over/underestimation patterns without pointing at individuals
• Use retrospectives to learn collectively

Conclusion

Planning Poker isn’t complicated, but there are subtleties. Keys to success:

1. Focus on relative comparisons, not absolute time
2. Value discrepancies - that’s where you learn
3. Keep reference stories - avoid estimate drift
4. Continuously improve - estimation retrospectives
5. Use appropriate tools - eliminate friction

Start Now

Ready for your first session? Create a free session on GoSprintPlanning - no registration, no installation.

More Questions?

• Complete Planning Poker Guide
• Fibonacci in Agile Estimation
• T-Shirt Sizing for Teams
• Scrum Team Velocity Guide