Español

Planning Poker: How Agile Teams Estimate Effort

Planning poker estimation cards fanned out for an agile team vote

Planning poker is the estimation technique that turns a potentially contentious backlog grooming session into a structured, surprisingly enjoyable team exercise. It sounds simple, but the mechanics are cleverly designed to surface the disagreements that matter most.

What is planning poker?

Planning poker (also called Scrum poker) is a consensus-based, gamified estimation technique used by agile teams to size user stories and backlog items. Each participant holds a hand of numbered cards. Everyone chooses a card privately, then all cards are revealed simultaneously. If estimates differ significantly, the team discusses the gap before voting again until they reach consensus.

The method was introduced by James Grenning in 2002 and later popularized by Mike Cohn in his book Agile Estimating and Planning (2005). Cohn's framing, along with the widespread adoption of Scrum, made planning poker the de-facto estimation tool in agile methodology teams worldwide.

The key insight behind planning poker is that estimation works best as a conversation, not a calculation. When everyone puts a number on the table at once, you get unfiltered individual judgment. The disagreements that follow are not friction -- they're the signal.

Key Facts

  • Teams using structured estimation techniques like planning poker report 29% higher confidence in their sprint commitments compared to unstructured sizing (State of Agile Report, 17th edition, 2024).
  • 81% of agile practitioners use story points as their primary estimation unit, with planning poker as the most common method for assigning them (State of Agile Report, 17th edition, 2024).
  • Mike Cohn, who popularized planning poker, observes that the technique's primary value is "the discussion it triggers, not the number it produces" (Mountain Goat Software, agileestimating.com).

Why planning poker works

Planning poker's effectiveness is not accidental. The design addresses three specific failure modes that plague traditional top-down estimation.

It reduces anchoring bias. When a senior developer says "this looks like a two-day task" before anyone else has spoken, it pulls the whole team toward that number regardless of individual expertise. Simultaneous card reveal breaks that dynamic entirely. Everyone commits to their estimate before seeing anyone else's, which gives the group genuinely independent data points.

It surfaces hidden assumptions. The interesting moment in any planning poker round is not when everyone agrees -- it's when the estimates scatter across multiple values. A developer who picks 3 while another picks 13 almost certainly have different mental models of what the story requires. That disagreement reveals a missing requirement, an unclear acceptance criterion, or a dependency nobody thought to mention. You want to find these gaps in the estimation meeting, not mid-sprint.

It engages the whole team. In many estimation approaches, a tech lead estimates and everyone else nods along. Planning poker gives every voice equal weight. The junior developer who picks a high card because she remembers a similar story that turned out to be much harder than expected gets to explain her reasoning. That institutional knowledge often doesn't surface any other way.

Planning poker also creates psychological ownership. When a team estimates together, they're more likely to hold each other accountable to the shared commitment -- because they made it together.

Common mistakes and limitations

Planning poker is effective, but it's easy to run poorly.

Rushing past disagreements. When two people are far apart, the temptation is to split the difference and move on. Don't. The gap is telling you something. Take three to five minutes to understand each perspective before re-voting.

Letting senior voices dominate. Even with simultaneous reveal, a tech lead who immediately explains their low card estimate before others have spoken can still anchor the discussion. Facilitators should ask the high-card holder to speak first.

Using it for everything. Planning poker is designed for user stories at the right level of granularity. Using it to size epics or multi-quarter initiatives produces numbers that aren't meaningful. Items that are too large should be split before estimation.

Treating the estimate as a promise. The number produced is a relative size estimate, not a deadline. Teams that confuse story points with hours create pressure that corrupts future estimates.

Running it without ready stories. If a story lacks clear acceptance criteria, planning poker becomes a debate about interpretation rather than effort. Items should meet a Definition of Ready before they enter estimation.

How to play planning poker (step by step)

Step 1: Set up the deck

Each participant gets a set of estimation cards. The standard deck uses a modified Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 20, 34, 55, 89, and special cards for "?" (too uncertain to estimate) and a coffee cup (need a break). The non-linear spacing reflects the truth that larger work carries proportionally more uncertainty. Most teams also add 0.5 and 1 at the low end for very small items.

Physical decks work fine. Online tools like Pointing Poker, PlanITpoker, and built-in features in Jira and Azure DevOps handle remote teams.

Step 2: Read the story aloud

The Product Owner (or whoever owns the backlog) reads the user story and acceptance criteria to the group. Participants ask clarifying questions. This is not the time to estimate -- it's the time to make sure everyone understands the same story. A two-to-three minute clarification window is typical.

Step 3: Estimate privately

Each participant selects a card from their hand that represents their size estimate for the story. Cards stay face-down. No one announces their number or reacts to anyone else during this phase. The goal is genuine independent judgment.

Step 4: Reveal simultaneously

On a count of three (or a button click in an online tool), everyone flips their card at the same time. This prevents the last person to reveal from being influenced by what others have shown.

Step 5: Discuss the outliers

If all cards show the same number (or adjacent numbers), the team records the consensus estimate and moves on. If there's significant spread, the facilitator asks the highest and lowest card holders to explain their reasoning. This is where the real value happens. Let the discussion run for three to five minutes, then re-vote.

Step 6: Re-vote to consensus

After the discussion, everyone re-estimates. Repeat Steps 3 through 5 until the group converges. In most cases, convergence happens in one or two rounds. If a story requires more than three rounds without converging, it may need to be split or deferred for more research.

Planning poker example

Here's a typical round for a story: "As a user, I want to reset my password via email so I can regain account access."

Estimator First vote Reasoning
Dev A 5 Standard auth flow, used a similar library before
Dev B 13 Forgot about email deliverability testing and edge cases for expired links
QA 8 Considers regression testing on login flows
Product Owner ? Not estimating complexity, asks clarifying question about token expiry rules

Discussion: Dev B raises that the team's last email-based feature hit unexpected deliverability issues in staging that added two days. Dev A acknowledges she hadn't factored in that testing overhead. The team agrees the story needs an acceptance criterion explicitly covering expired token behavior before re-voting.

Re-vote: Dev A: 8, Dev B: 8, QA: 8. Consensus at 8 story points.

The final estimate is 60% higher than the first vote from Dev A. That gap was not a mistake -- it was the system working.

Planning poker tools and decks

Physical cards work well for co-located teams. Printed decks are inexpensive and add a tactile ritual to the meeting. A quick search for "planning poker cards" returns many options, including free printable templates.

Online tools are the default for distributed teams:

  • Pointing Poker (pointingpoker.com) -- simple, free, no signup required
  • PlanITpoker (planitpoker.com) -- includes history and session management
  • Jira -- native planning poker via the Sprint Planning board (requires a third-party app)
  • Azure DevOps -- integrates via extensions like Estimate

The card values teams use most:

Deck type Values
Modified Fibonacci (standard) 0, 1, 2, 3, 5, 8, 13, 20, 40, 100
Pure Fibonacci 1, 2, 3, 5, 8, 13, 21, 34, 55, 89
T-shirt + numbers hybrid XS=1, S=2, M=3, L=5, XL=8
Powers of 2 1, 2, 4, 8, 16, 32

Most teams stick with modified Fibonacci. The gaps between large numbers (13 vs. 20 vs. 40) reflect genuine uncertainty at scale, which is the honest position to take.

Best practices

Do prepare your backlog before the session. Stories that lack acceptance criteria waste the whole team's time. Run a quick pre-grooming pass so items meet a Definition of Ready before estimation begins.

Do time-box each story. A two- to three-minute discussion limit per story keeps the session moving. If a story keeps consuming time, split it.

Do rotate the facilitator. Keeping the same person running every session creates a power dynamic that can subtly suppress dissenting estimates. Rotating keeps everyone equally invested.

Don't anchor before the reveal. Avoid statements like "this seems small" or "I spent three days on something similar" before cards are shown. These color the estimate before the reveal has a chance to produce independent data.

Don't use story points as hours. The whole point of relative sizing is to decouple effort from calendar time. Once story points become a proxy for hours, you lose the velocity signal they're designed to produce.

Don't skip the high-card explanation. The person with the highest card usually has information the rest of the team doesn't. Their explanation is often the most valuable three minutes of the session.

Frequently asked questions

Why do all cards reveal at the same time?

Simultaneous reveal prevents anchoring. If estimates came out one at a time, each person would be influenced by the numbers already visible. The whole point is to collect independent judgments and then compare them, not to reach agreement through sequential social pressure.

How long should planning poker take?

For a two-week sprint planning session, most teams estimate 15 to 30 backlog items and budget 60 to 90 minutes for the estimation portion. Stories that take longer than five minutes to estimate are usually a signal they need to be split or better defined.

How does planning poker compare to t-shirt sizing?

Both are relative estimation methods. T-shirt sizing (XS, S, M, L, XL) is faster and works well for early-stage roadmap planning or when audiences include non-technical stakeholders. Planning poker produces more granular outputs (actual numbers on a scale) and forces more explicit discussion, making it better suited for sprint planning where the team needs commitments it can track with a burndown chart.

What if the team never reaches consensus?

If multiple rounds don't converge, the story probably needs more work. Common causes: the scope is unclear, the story spans multiple independent concerns, or there's a dependency nobody fully understands yet. The right move is to table the item, assign an owner to clarify it, and re-estimate next session.

Can planning poker work for non-software teams?

Yes. Any team estimating relative effort -- marketing campaigns, content production, operations projects -- can use the technique. The card values and story format translate directly. What doesn't transfer is using software-specific story points; non-software teams often substitute effort tiers (Low, Medium, High, Very High) mapped to numbers for the same effect.

Planning poker's staying power in agile methodology comes down to one thing: it makes estimation a team conversation instead of an individual prediction. The number you get at the end is useful for tracking sprint planning commitments and burndown chart velocity. But the real output is the shared understanding of what a story actually involves -- and that understanding is what makes the sprint work.