Planning Poker Frequently Asked Questions
Planning Poker Frequently Asked Questions
Estimated reading time: 18–22 minutes
Planning Poker is simple to learn, but teams quickly discover that the mechanics are only the beginning.
Once a team starts estimating real work, practical questions appear:
Should bugs receive story points?
Should Product Managers vote?
What happens when estimates are wildly different?
Is a 13-point story too large?
Should story points convert to hours?
Can remote teams use Planning Poker effectively?
What if the team cannot agree?
This FAQ answers the most common Planning Poker and Agile estimation questions in a practical, team-oriented way. The goal is not to define a rigid process every team must follow. The goal is to help teams make better estimation decisions without turning Planning Poker into bureaucracy.
Planning Poker Basics
What is Planning Poker?
Planning Poker is a collaborative estimation technique used by Agile teams to estimate the relative effort of user stories or backlog items.
Each participant privately selects an estimate, usually from a Fibonacci-style deck. Votes are revealed simultaneously. If estimates differ, the team discusses assumptions, clarifies scope, and votes again if needed.
The value of Planning Poker is not just the final number. The value is the conversation that exposes hidden complexity before work begins.
Why is it called Planning Poker?
It is called Planning Poker because early teams used physical cards, similar to playing cards, to reveal estimates. Each participant selected a card privately and revealed it at the same time as everyone else.
The "poker" part refers to hidden cards and simultaneous reveal, not gambling.
Is Planning Poker required in Scrum?
No. Scrum does not require Planning Poker, story points, or Fibonacci numbers.
Planning Poker is a common Agile estimation practice because many Scrum teams find it useful, but it is not mandatory. A Scrum team can use Planning Poker, T-shirt sizing, affinity estimation, flow metrics, or no estimates at all depending on its planning needs.
What problem does Planning Poker solve?
Planning Poker helps reduce anchoring bias and groupthink during estimation.
In a traditional meeting, the first estimate spoken often influences everyone else. Planning Poker prevents that by requiring independent estimates before discussion.
It also encourages quieter team members to participate and helps uncover assumptions that would otherwise remain hidden.
What is the goal of Planning Poker?
The goal is shared understanding.
The estimate is useful, but it is not the only outcome. A good Planning Poker session helps the team clarify scope, identify unknowns, discuss risks, and decide whether the work is ready for sprint planning.
Story Points
What are story points?
Story points are a unit of relative effort used by Agile teams.
They usually reflect a combination of:
Complexity
Amount of work
Technical uncertainty
Risk
Testing effort
Integration effort
A story estimated as 8 points is not eight hours. It is larger or more uncertain than a 5-point story.
Are story points the same as hours?
No.
Story points are not hours, days, or calendar time. They are relative estimates.
Converting story points directly into hours is one of the most common Agile estimation mistakes. It removes the benefit of relative estimation and pushes the team back toward false precision.
Why do teams use story points instead of hours?
Teams use story points because software work is difficult to predict precisely.
Developers are usually better at comparing work than forecasting exact durations. It is easier to ask, "Is this bigger than the password reset story?" than, "Will this take exactly 11 hours?"
Story points help teams reason about effort without pretending they can perfectly predict time.
Can story points be converted into days?
They should not be converted directly.
A team may use historical velocity to forecast how much work it tends to complete in a sprint, but that is different from saying one point equals one day.
For example, if a team completes about 35 points per sprint, that helps with sprint planning. It does not mean each point has a fixed number of hours behind it.
Should every backlog item have story points?
Not necessarily.
Teams usually estimate work that meaningfully competes for sprint capacity. Very small administrative tasks, simple copy edits, or obvious chores may not need formal estimation.
The point of estimation is to support planning, not to assign numbers to everything for its own sake.
Fibonacci Estimation
Why do Agile teams use Fibonacci numbers?
Agile teams use Fibonacci numbers because the gaps between values increase as estimates get larger.
That matters because uncertainty grows as work gets larger. A team can often distinguish a 1-point story from a 2-point story, but the difference between a 21 and a 22 is usually meaningless.
Fibonacci-style scales avoid false precision.
What Fibonacci values should a team use?
A common Planning Poker deck uses:
Some teams add:
There is no single required deck. The best deck is one the team understands and uses consistently.
Is a 13-point story too large?
Not always, but it is a signal.
A 13-point story often means the work is large, uncertain, or has multiple moving parts. The team should ask whether it can be split, refined, or clarified before entering a sprint.
Many teams treat anything above 13 as too large for sprint-ready work.
Should teams use 21, 40, or 100?
Only if those numbers are useful signals.
For many teams, values above 13 simply mean "too big" or "not ready." If the team is debating whether something is 40 or 100, the better question is usually, "How should we break this down?"
Why not estimate from 1 to 10?
A 1-to-10 scale invites false precision.
Teams may waste time debating whether something is a 6 or a 7, even though that distinction rarely improves planning. Fibonacci forces more meaningful choices: is this closer to a 5 or an 8?
Voting and Consensus
Who should vote in Planning Poker?
The people responsible for delivering the work should vote.
That usually includes engineers and QA. Designers, product managers, architects, or managers may participate depending on the work and team structure.
The key question is: does this person understand or contribute to the delivery effort?
Should Product Managers vote?
Usually, Product Managers should participate in discussion but not vote on implementation effort.
Product owns priority, user value, and scope. The delivery team owns the estimate. Product can clarify requirements, remove scope, or change priority, but should not pressure the team into a lower estimate.
Should QA vote?
Yes.
Testing complexity is part of delivery effort. QA often identifies edge cases, regression risk, environment issues, and verification work that developers may miss.
Excluding QA frequently leads to underestimation.
Should engineering managers vote?
It depends.
If the engineering manager is close to the codebase and materially understands the implementation, their estimate may be useful. If they are primarily attending to monitor or manage, they should not vote.
Planning Poker works best when participants feel safe disagreeing.
What if one person always estimates higher?
Listen carefully.
A consistently higher estimator may be accounting for risk others are missing. They may include testing, deployment, edge cases, or operational impact more consistently than the rest of the team.
If the pattern continues, compare assumptions against reference stories and clarify what the team includes in an estimate.
What if one person always estimates lower?
A consistently lower estimator may know about reusable code, simpler implementation paths, or ways to reduce scope.
They may also be undercounting testing, risk, or integration effort.
As with high estimates, the answer is discussion rather than correction.
Should the team average votes?
No.
Averaging hides disagreement.
If votes are:
The important part is not the average. The important part is understanding why someone voted 13 and someone else voted 3.
Planning Poker is designed to expose differences in assumptions.
What if the team cannot agree?
If the team cannot agree after discussion, the story probably needs more refinement.
The facilitator can ask:
Are we estimating the same scope?
Are acceptance criteria clear?
Are dependencies known?
Is the story too large?
Do we need a spike?
Forcing consensus on unclear work creates false confidence.
Facilitation
How long should a Planning Poker session last?
Most estimation sessions should last 30 to 60 minutes.
If a team regularly needs more than an hour, it may be estimating too many items, bringing unclear stories, or allowing discussions to drift into design debates.
Shorter, more frequent sessions usually work better.
When should Planning Poker happen?
Planning Poker often works best during backlog refinement, before sprint planning.
Sprint planning should not be the first time the team sees the work. Estimating earlier gives Product time to clarify scope and gives Engineering time to identify risks before commitment.
What makes a story ready for estimation?
A story is ready for estimation when the team understands enough to make a reasonable relative estimate.
It should usually have:
Clear user or business goal
Acceptance criteria
Known scope
Major dependencies identified
Relevant designs or technical notes
Open questions captured
The story does not need to be perfect, but it should be understandable.
What should a facilitator do?
The facilitator protects the quality of the conversation.
They should:
Prevent anchoring
Keep the backlog item visible
Invite quieter voices
Ask high and low voters to explain
Capture follow-ups
Timebox discussions
Send unclear work back to refinement
The facilitator does not need to have all the answers. They need to keep the process useful.
How do you prevent anchoring?
Require silent voting before discussion.
No one should announce an estimate before the reveal. After the reveal, the team can discuss differences and revote.
This preserves independent thinking.
How do you stop estimation from becoming a design meeting?
Ask:
"Do we need to solve this now to estimate the story?"
If yes, continue briefly.
If no, capture a follow-up and move on.
Some technical discussion is necessary. Full solution design usually belongs in a separate conversation.
Remote Planning Poker
Can remote teams use Planning Poker effectively?
Yes.
Remote Planning Poker can work extremely well when votes are hidden, backlog items are clear, and the facilitator keeps the team engaged.
Remote teams should be especially intentional about documentation, participation, and timeboxing.
Should remote Planning Poker be live or async?
Both can work.
Live estimation is best for complex work, new teams, or stories with high uncertainty.
Async estimation can work for clear, familiar backlog items. If async votes differ widely, the team should schedule a short live discussion.
How do you keep remote estimation sessions engaging?
Keep them short and structured.
Useful practices include:
Keep the active story visible
Require everyone to vote
Ask outlier voters to explain
Use timers for long discussions
Capture decisions immediately
Estimate fewer items per session
Remote estimation suffers when teams try to estimate too much at once.
Should cameras be required?
Usually no.
Cameras can improve engagement, but requiring them may not be practical for every team. Participation matters more than video.
A person who votes thoughtfully and explains assumptions is contributing, whether their camera is on or off.
Bugs, Spikes, and Technical Work
Should bugs receive story points?
Yes, if they require meaningful engineering effort and compete for sprint capacity.
A typo may not need points. A production bug involving unclear reproduction steps, data correction, regression testing, and deployment risk probably should.
Should spikes receive story points?
Teams vary.
Some estimate spikes. Others timebox them without points.
The important thing is that a spike should answer a specific question. A vague spike like "Investigate billing" is less useful than "Determine whether our payment provider supports prorated seat changes through the API."
Should technical debt receive story points?
Yes, if it consumes team capacity.
Technical debt work can include significant complexity, risk, testing, and deployment effort. It should be estimated like other work when it competes with product backlog items.
Should infrastructure work be estimated?
Yes, when it affects sprint capacity.
Infrastructure work often has hidden complexity: environments, deployment sequencing, observability, rollback plans, and cross-team dependencies. It should not be ignored simply because it is not a user-facing feature.
Velocity and Forecasting
What is velocity?
Velocity is the amount of estimated work a team completes in a sprint, usually measured in story points.
If a team completes 34, 38, and 36 points over three sprints, it can use that history to forecast future capacity.
Can velocity compare teams?
No.
Velocity is team-specific. A team completing 50 points is not automatically more productive than a team completing 30.
Different teams estimate differently, work on different systems, and face different constraints.
Should teams have velocity targets?
No.
Velocity is a planning signal, not a performance goal. Once teams are measured against velocity targets, estimates tend to inflate and the metric becomes less useful.
What should teams do if velocity is unstable?
Look for causes:
Team membership changes
Unclear backlog items
Large stories
Unplanned work
Production support
Dependencies
Scope changes
Inconsistent definition of done
Velocity is a symptom. Investigate the system around it.
Common Problems
Why does everything become an 8?
If everything becomes an 8, the team may lack reference stories, avoid hard conversations, or bring stories that are too large or too vague.
Recalibrate with completed work and split oversized stories.
Why do estimates keep being wrong?
Estimates are forecasts, not guarantees.
Repeated surprises may indicate:
Missing acceptance criteria
Hidden dependencies
Testing complexity
Scope changes
Stories that are too large
Lack of reference stories
Use retrospectives to improve the estimation model.
What if Product pressures the team to lower estimates?
Product can negotiate scope, but should not pressure estimates downward.
A healthy question is:
"What would need to come out of scope for this to be a 5?"
The estimate should change only when the work changes.
What if the team hates estimation?
Find out why.
Teams often hate estimation because it has been used against them, turned into time tracking, or made into a performance metric. Fixing those problems matters more than changing the estimation technique.
Can teams stop estimating?
Some mature teams use flow metrics instead of story point estimation.
This can work when teams have stable work types, strong delivery discipline, and good throughput data. Newer teams often benefit from estimation because it forces useful planning conversations.
Best Practices
What are the most important Planning Poker best practices?
Start with these:
Vote silently before discussion.
Discuss the highest and lowest estimates.
Use reference stories.
Keep story points separate from hours.
Include QA and delivery perspectives.
Split large stories.
Treat estimates as forecasts.
Use velocity only for team planning.
Estimate before sprint planning.
Review surprises without blame.
How can a new team get started?
Start simple.
Choose a small Fibonacci deck, estimate a handful of ready stories, and create reference examples as you complete work. Do not worry about perfect velocity at first. Focus on building a shared understanding.
How often should teams recalibrate estimates?
Recalibrate when:
Team membership changes
Architecture changes
The product changes significantly
Estimates consistently feel wrong
Reference stories become outdated
Calibration should be lightweight and practical.
Key Takeaways
Planning Poker is useful because it creates better estimation conversations.
Story points are relative estimates, not hours.
Fibonacci numbers help represent increasing uncertainty.
Wide vote spreads should trigger discussion, not averaging.
Product owns scope and priority; the delivery team owns estimates.
Remote Planning Poker works well when facilitated intentionally.
Velocity should support planning, not performance management.
Good estimation improves shared understanding before sprint commitment.
Related Reading
Plain Old Planning Poker
Ready to run faster estimation sessions?
Free planning poker for agile teams. Real-time voting, Fibonacci decks, and Jira integration — no credit card required.
Get started free