Planning Poker Guide — Rules, Fibonacci & Online Tool | Toolsbase

What Is Planning Poker?

Planning poker — also known as poker planning, scrum poker, or estimation poker — is a consensus-based story point estimation technique used by agile teams to size user stories. Every team member simultaneously reveals a Fibonacci estimation card, preventing any single person's opinion from anchoring the group.

The technique was introduced by James Grenning in 2002 and popularized by Mike Cohn in Agile Estimating and Planning (2005). Today it is the most widely used story-point estimation method in Scrum and Kanban teams worldwide, typically using a modified Fibonacci estimation template (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100) or T-shirt sizing.

Want to run a session right now? Try our free online Planning Poker tool — no sign-up required.

Why "Poker"?

In typical meetings, the first person to speak—or the most senior—tends to anchor the group's opinion. Planning poker eliminates this cognitive bias by having everyone commit to a number before anyone reveals theirs. Like a poker hand, cards stay hidden until the moment of reveal.

History and Origins

James Grenning's Original Paper (2002)

Planning poker was first described by James Grenning in a 2002 paper titled "Planning Poker or How to Avoid Analysis Paralysis while Release Planning." Grenning was frustrated with traditional estimation meetings where a single expert's guess became the team's estimate without any real discussion.

His insight was simple: if everyone commits to a number independently and simultaneously, you surface the full range of the team's knowledge in a single moment. The outliers — the person who went high and the person who went low — are almost always reacting to something real. Making them explain their reasoning is where the estimation value actually comes from.

Mike Cohn's Popularization (2005)

Mike Cohn included planning poker in Agile Estimating and Planning, one of the most influential Agile books ever written. Cohn connected it to the Fibonacci-based card sequence and framed it within the broader practice of story point estimation. After the book's publication, planning poker was rapidly adopted by Scrum teams across the software industry.

Digital Transformation

As remote and distributed work became common through the 2010s, physical card decks gave way to digital tools. Today, dozens of online planning poker platforms exist — including the Planning Poker tool on this site — enabling globally distributed teams to run sessions with the same simultaneous reveal and discussion mechanics as the original physical version.

Basic Rules

Card Values

Planning poker uses a modified Fibonacci sequence.

Card	Meaning
0	No work needed (already done, etc.)
1	Trivial effort
2	Small effort
3	Slightly small effort
5	Medium effort
8	Somewhat large effort
13	Large effort (consider splitting)
21	Very large effort (must split)
?	Can't estimate (insufficient information)
☕	Need a break

The widening gaps reflect the reality that precision decreases as tasks grow larger. Debating "13 or 14" wastes time; "13 or 21" is the right granularity.

Participant Roles

Role	Participation	Responsibility
Product Owner (PO)	Explains the story	Provide context and acceptance criteria
Scrum Master (SM)	Facilitator	Manage discussion flow and time
Development Team	Play cards	Estimate and explain reasoning
Stakeholders	Observer	Answer questions (do not play cards)

Only the development team plays cards. When POs or managers participate in estimation, implicit pressure distorts the results.

Modified Fibonacci vs. T-Shirt Sizing vs. Other Scales

Not all teams use the same card set. Here is a practical comparison of the most common estimation scales.

Modified Fibonacci (Most Common)

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

The modified Fibonacci sequence is the default for most Scrum teams. The increasing gap between values is its greatest strength — it forces teams to acknowledge that large stories carry large uncertainty, and it naturally discourages false precision on complex work.

Best for: Established Scrum teams who already think in story points, and teams who want their estimates to feed directly into velocity tracking.

Limitation: New team members sometimes struggle to calibrate what "5 points" means without a well-established reference story.

T-Shirt Sizing

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

T-shirt sizing trades numerical precision for intuitive clarity. Most people have an immediate feel for whether something is "small" or "extra-large." This makes it particularly effective for early-stage backlog grooming and roadmap planning when work is not yet well-defined.

Best for: Product discovery phases, roadmap prioritization, or teams who find numbers overly precise for rough planning.

Limitation: You lose direct compatibility with velocity metrics. Teams often need to map sizes to numeric values later if they want to track throughput.

Powers of 2

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

Some teams prefer the clean doubling logic of powers of 2. The rule is simple: each card is exactly twice the previous. This can feel more intuitive than Fibonacci for some teams.

Best for: Teams with a strong engineering culture who prefer explicit doubling semantics.

Limitation: The gap between 16 and 32 is enormous, which can make it hard to differentiate between genuinely large and ginormous stories.

Linear Scale

Cards: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10

A linear scale feels natural but is the least recommended for planning poker. Linear gaps encourage false precision ("is this a 6 or a 7?") and undermine the core purpose of relative sizing.

Best for: Rarely recommended. Possibly useful for very short-horizon tasks with high certainty.

Which Scale Should You Choose?

Scenario	Recommended Scale
General Scrum team	Modified Fibonacci
Early-stage roadmap planning	T-Shirt Sizing
Strong engineering culture	Powers of 2
Mapping to time explicitly	Avoid planning poker; use time-boxing instead

The most important thing is that your team uses the same scale consistently so that estimates are comparable across sprints and can feed into velocity tracking. Use the Story Point Calculator to convert between scales if you need to compare estimates.

Step-by-Step Process

Step 1: Story Presentation (2–3 minutes)

The product owner reads the user story and explains the context and acceptance criteria.

User Story:
"As a user, I want to download my order history as CSV
 so I can import it into my budgeting app."

Acceptance Criteria:
- Covers orders from the past 12 months
- CSV includes date, product name, amount, and status
- Download button placed on the order history page

Step 2: Questions and Discussion (3–5 minutes)

The team asks clarifying questions. The goal is to resolve ambiguity, not to design the solution.

Typical questions:

"Are there performance requirements if the user has 10,000+ orders?"
"Is UTF-8 the required CSV encoding?"
"Do we need filters (date range, etc.)?"

Step 3: Simultaneous Card Reveal

After questions, each member selects a card. On the facilitator's signal, everyone reveals simultaneously.

Alice: 5
Bob:   5
Carol: 8
Dave:  13

Step 4: Discuss Divergence (2–5 minutes)

When cards differ significantly (typically a gap of two or more levels), the highest and lowest explain their reasoning.

Dave (13): "Generating CSV for large datasets needs async processing.
            We'd need to implement a job queue."

Alice (5):  "We can reuse the existing report module's CSV generator.
            New code would be minimal."

This discussion surfaces assumptions and blind spots the team hadn't considered.

Step 5: Re-vote and Converge

After discussion, the team votes again. If consensus still isn't reached:

Take the higher value: When in doubt, round up
Split the story: Lack of consensus often signals a story that's too large
Create a spike: For high technical uncertainty, time-box an investigation

Planning Poker for Distributed and Remote Teams

Remote planning poker introduces unique challenges: connection latency, the absence of nonverbal cues, and the temptation for participants to disengage during others' discussions. Here is a practical playbook for making remote sessions as effective as in-person ones.

Choose the Right Tool

A purpose-built online Planning Poker tool provides simultaneous card reveal — arguably the most important mechanic to preserve remotely. Avoid makeshift solutions like polling or chat reveals, which allow participants to change their answer after seeing others'.

Key features to look for:

Simultaneous reveal (cards hidden until everyone votes)
Room sharing via a simple link (no account required for participants)
Visible participant list (so the facilitator knows who hasn't voted)
Timer to enforce time boxes
History of past estimates for reference

Establish Ground Rules Before You Start

In face-to-face sessions, social norms naturally govern turn-taking and engagement. Remote sessions need explicit rules:

Cameras on during discussion rounds
Mute when not speaking to reduce audio fatigue
Use the chat channel to share written questions before speaking
No side conversations in other windows while voting

Manage Asynchronous Time Zones

For teams spanning more than two or three time zones, synchronous planning sessions can become a genuine burden. Practical approaches:

Overlap windows: Schedule sessions during the two-hour window that overlaps for both time zones, even if it is early or late for some participants.
Async pre-estimation: Use a shared document to collect questions and preliminary thoughts before the synchronous session — this compresses the live meeting significantly.
Async voting (for straightforward stories): Some online tools support asynchronous card submission, where each participant votes when convenient and the facilitator reveals results at a scheduled time.

Energize the Remote Room

Online fatigue is real. Keep sessions engaging:

Rotate facilitators: Sharing the facilitation role builds team ownership and reduces facilitator fatigue.
Celebrate fast consensus: When the team nails a quick unanimous vote, acknowledge it — it builds positive momentum.
Break every 45–60 minutes: Remote cognitive load is higher than in person. Honor the ☕ card.
Use breakout rooms for long debates: If two people are deep in a technical discussion, move them to a breakout room while the rest of the team votes on easier stories.

Handling Connectivity Issues

Always have a backup plan:

If someone drops out mid-session, decide in advance whether to wait or proceed without them.
Use a shared document as a fallback for recording votes if the online tool has issues.
Keep the session link in the team's persistent chat channel for quick rejoin.

Integration with Sprint Planning

Planning poker is typically run during backlog refinement (also called backlog grooming) in the days before sprint planning. Understanding how the two ceremonies relate helps teams get the most out of both.

Where Planning Poker Fits in the Scrum Cycle

Product Backlog → Backlog Refinement → Sprint Planning → Sprint → Review → Retrospective
                        ↑
               Planning Poker lives here

Backlog refinement is the ideal home for planning poker because:

Stories are still malleable: If estimation reveals a story is too large or unclear, there is still time to split or refine it before sprint planning.
Decisions are low-pressure: The team is not yet committing to a sprint; they are simply understanding and sizing work.
Multiple sessions per sprint: Refinement typically happens once or twice per sprint, keeping the backlog continuously groomed.

What Sprint Planning Assumes

Sprint planning works best when it can assume that backlog items arriving at the meeting are already estimated and well-understood. The goal of the sprint planning meeting is to select and commit, not to estimate for the first time.

When teams skip refinement and try to estimate during sprint planning, sessions become long and unfocused, and teams often end up committing to stories they don't fully understand.

Using Velocity to Inform Sprint Capacity

Once stories are estimated, use your team's historical velocity to set a realistic sprint goal. Velocity is the average story points completed per sprint over the last 3–5 sprints.

Use the Velocity Calculator to compute your team's rolling average and set a sustainable pace for the upcoming sprint. Avoid the temptation to inflate the sprint commitment "just this once" — consistent, sustainable velocity is far more valuable than heroic one-off sprints.

The Sprint Planning Meeting with Pre-Estimated Stories

With a well-refined backlog, sprint planning typically follows this flow:

Review sprint goal (5 minutes): The PO articulates the overarching theme for the sprint.
Story selection (20–30 minutes): The team selects stories from the top of the backlog until the sprint capacity (velocity) is filled.
Task breakdown (30–45 minutes): The team breaks selected stories into specific development tasks.
Commitment (5 minutes): The team confirms they believe the selected scope is achievable.

Stories that were not estimated in refinement should be flagged during sprint planning and either estimated quickly (if simple) or moved to the next sprint.

Running Planning Poker Online

Remote teams rely on digital tools for planning poker sessions.

Benefits of Online Tools

Guaranteed simultaneous reveal (no peeking)
Automatic result recording and statistics
Built-in timers for time management
Support for asynchronous estimation

Online-Specific Tips

Remote communication carries less information than face-to-face. Compensate by:

Turning cameras on: Facial expressions enrich discussion
Using chat alongside voice: Supplement verbal discussion with written notes
Enforcing time boxes strictly: Online meetings tend to drag
Active facilitation: Consciously balance speaking time across the team

Tips for Effective Discussions

Set a Time Box

Limit each story to 5 minutes maximum. If the team can't converge in 5 minutes, the story itself likely needs refinement.

Use the "?" Card

If information is insufficient, play "?" instead of guessing a number. When a "?" appears, identify what's missing and either resolve it on the spot or log it for follow-up.

Always Refer to the Reference Story

When discussion drifts, bring it back to the baseline.

"Compared to our reference story (adding a phone number field = 3 points),
 how does this story measure up?"

Draw Out Every Voice

The facilitator should actively invite quieter members to share their perspective. New team members often spot assumptions the rest of the team takes for granted.

Common Challenges and Solutions

Challenge 1: Sessions Take Too Long

Symptom: 10 stories take 2 hours.

Solutions:

Set a per-story time limit (5 minutes)
Share stories in advance and collect questions beforehand
Batch small stories (obviously 1–2 points) for quick consensus
Cap sessions at 90 minutes

Challenge 2: The Same People Always Give the Highest/Lowest Estimates

Symptom: Cautious Alice always goes high; optimistic Bob always goes low.

Solutions:

Review past estimates vs. actuals to see whose instincts are closest
After each estimate, confirm what's included and excluded
Consistently anchor to the reference story

Challenge 3: The PO Pressures the Estimates

Symptom: "That's 5 points? Can't it be done in 3?"

Solutions:

Clarify that the PO's role is to explain stories and answer questions, not to set estimates
If an estimate feels high, adjust scope (reduce acceptance criteria) rather than override the estimate
Reinforce that estimates are the team's professional judgment

Metrics and Tracking Estimation Accuracy

Planning poker is only as valuable as the learning loop it creates. Without measurement, teams have no way to know whether their estimation is improving or whether systematic biases are going unaddressed.

The Core Metric: Estimate vs. Actual

After every sprint, compare each completed story's estimated points to its actual complexity. "Actual complexity" is inherently subjective, but a useful proxy is asking the team: "If we were to estimate this story today, knowing everything we now know, what would we give it?"

Story	Estimated	Actual (retrospective)	Ratio
CSV export	5	5	1.0
Payment gateway	8	13	1.63
User onboarding	13	8	0.62
Search autocomplete	3	3	1.0

A ratio consistently above 1.0 means the team is underestimating; below 1.0 means overestimating.

Velocity Trend Analysis

Track your team's velocity sprint by sprint. A healthy velocity graph is relatively stable, with natural variance of roughly ±20%. Large spikes or drops are diagnostic signals:

Sudden drop: A story was much harder than estimated, or the team encountered unplanned work.
Sudden spike: The team over-delivered — either estimates were inflated, or the sprint contained unusually simple work.

Use the Velocity Calculator to visualize your velocity trend and flag anomalies automatically.

Calibration Reviews

Every 4–6 sprints, run a calibration session:

Pull the last 20–30 completed stories with their estimated and actual points.
Identify systematic patterns: are certain story types (infrastructure, UI, integration) consistently over- or under-estimated?
Adjust your reference stories for those types.
Discuss whether your Fibonacci scale is calibrated correctly — if your team never uses 1 or 2, or always ends up at 13+, the scale may need recalibration.

What Not to Measure

Individual estimation accuracy: Never track whose cards were closest on a per-person basis. Estimation is a team activity, and individual scoring destroys psychological safety.
Estimation compliance: Don't measure whether everyone is "playing correctly." Compliance pressure turns planning poker into a checkbox exercise.
Speed of consensus: Rapid consensus is not inherently good. It may signal that the team is rubber-stamping estimates without genuine discussion.

Leading Indicators of Improving Estimation

The gap between highest and lowest card decreases over time (more shared understanding)
"?" cards become rarer (stories arrive at refinement better defined)
Velocity variance narrows sprint over sprint
Retrospective discussion of estimation misses becomes shorter and more constructive

Connecting to Retrospectives

Sprint retrospectives are the ideal time to review estimation accuracy.

What to Review

Compare completed stories' estimates to their actual complexity
Analyze stories that were significantly over- or under-estimated
Check whether estimation assumptions held true
Share learnings for the next estimation session

Critically, never use retrospectives to blame individuals for estimation misses. Estimates are forecasts — being wrong is natural. The goal is team learning, not accountability.

FAQ

What is the difference between story points and planning poker?

Story points are the unit of measure; planning poker is the process for agreeing on them. You can assign story points without planning poker (e.g., one person estimates in isolation), and you can run planning poker with other scales like T-shirt sizes. In practice, the two are closely associated because planning poker is the most widely used method for arriving at story-point estimates.

How many stories can a team estimate in one session?

A well-run session of 60–90 minutes typically covers 10–20 stories, assuming the stories are reasonably well-defined before the session starts. Stories that require significant clarification will take longer. If you are consistently estimating fewer than 8 stories per 90-minute session, invest more time in pre-refinement story preparation.

Should the product owner vote in planning poker?

No. The product owner's role is to explain the story and answer questions about scope and acceptance criteria. If POs vote, their estimates carry implicit authority that can anchor the team's judgment — especially if the PO is also a manager. The PO should remain engaged and available throughout the session but should not reveal cards.

What should the team do if they can't reach consensus after two rounds?

After two rounds without consensus, the facilitator should take one of three actions: (1) accept the higher estimate and move on, (2) agree to split the story into smaller, more estimable pieces, or (3) schedule a spike — a time-boxed investigation task — to reduce technical uncertainty before estimating again.

Is planning poker useful for Kanban teams (not just Scrum)?

Yes. While planning poker was designed with Scrum in mind, Kanban teams can use it for backlog grooming and prioritization. In a Kanban context, the estimates often inform cycle time predictions rather than sprint capacity planning, but the discussion value is identical.

How do you run planning poker with a very large team (10+ people)?

Large teams (10+) should consider splitting into two groups for the estimation session and then comparing results. Alternatively, use a "voting representative" model where sub-teams nominate one person to represent their estimate. The goal is to preserve the diversity of perspectives without making discussions unwieldy.

What is a "spike" in planning poker?

A spike is a time-boxed research or investigation task added to the sprint to reduce uncertainty about a story that is too risky or unknown to estimate. After the spike, the team estimates the original story with better information. Spikes are themselves sized in hours, not story points, since they are fixed-duration by definition.

How often should a team recalibrate its story point scale?

Recalibration is warranted when the team notices systematic drift — estimates are consistently too high or too low relative to actuals, or the team's composition or technology stack has changed significantly. A lightweight calibration review every 4–6 sprints is a healthy default.

Is "poker planning" the same as planning poker?

Yes — "poker planning," "scrum poker," "agile poker," and "estimation poker" are all common alternative names for the same technique. The canonical term coined by James Grenning in 2002 is "planning poker," but the word order is often flipped in casual usage. Whatever you call it, the rules, Fibonacci estimation card values, and simultaneous-reveal mechanic are identical.

What's the best Fibonacci estimation template for a new Scrum team?

Start with the modified Fibonacci sequence (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100) plus "?" for unknowns and "∞" for "too big to estimate." It's the most widely adopted template and the one Mike Cohn recommends in Agile Estimating and Planning. Our free online planning poker tool ships with this template preloaded, along with standard Fibonacci, T-shirt sizing, and powers-of-2 as alternative card decks.

Can I use planning poker without a physical card deck?

Yes — and most teams do. Online estimation poker tools like the one on this site provide the same independent-selection, simultaneous-reveal mechanics as a physical deck, but work for remote and hybrid teams. Paper cards still have a nostalgic charm for co-located teams, but for distributed work an online tool is practical, faster to reset between stories, and captures the estimation history automatically.

Summary

Planning poker harnesses the independent judgment of every team member to produce reliable, bias-free estimates. Simultaneous card reveals eliminate anchoring, and the follow-up discussion between high and low estimators deepens the team's understanding of each story.

Combined with a well-chosen estimation scale, disciplined integration with sprint planning, and retrospective-driven calibration, planning poker steadily improves a team's estimation confidence and accuracy over time.

Ready to run your next session? Use our free online Planning Poker tool and pair it with the Velocity Calculator to keep your sprint commitments grounded in data.