Guide
12 min read

The Complete Guide to Planning Poker for Agile Teams

Everything you need to know about planning poker estimation, from basic concepts to advanced techniques for distributed teams.

Published on January 15, 2024
Planning Poker
Agile
Estimation
Scrum

The Complete Guide to Planning Poker for Agile Teams

Ever sat through an estimation meeting where the loudest developer dominated the conversation, only to discover three sprints later that your "simple" feature took twice as long as predicted? You're not alone.

Planning poker flips this script. Instead of one person driving estimates, it gets your entire team—developers, testers, designers—to weigh in simultaneously. The result? More accurate estimates, fewer surprises, and way less arguing about whether something is a 3 or a 5.

What is Planning Poker?

Planning poker (also called Scrum poker) is a team-based estimation technique where everyone votes on how complex or time-consuming a task will be. Think of it as democratic estimation—no single voice dominates, and you get the benefit of diverse perspectives.

Teams typically estimate using story points, ideal days, or other units they agree on. The magic isn't in the numbers themselves, but in the discussions they spark.

How It Works

Each team member gets a deck of cards with values representing complexity or effort. Common decks include:

  • Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21
  • Modified Fibonacci: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100
  • T-shirt sizes: XS, S, M, L, XL
  • Powers of 2: 1, 2, 4, 8, 16, 32

The Planning Poker Process

Step 1: Prep Your Backlog

Before the session, make sure each user story has:

  • Clear acceptance criteria
  • Enough detail to estimate (not implementation details, just clarity on what "done" looks like)
  • Answers to obvious questions

If a story doesn't meet these criteria, don't estimate it—refine it first.

Step 2: Pick a Moderator

The moderator (usually the Product Owner or Scrum Master) presents each story and keeps things moving. Their job is facilitating, not influencing estimates.

Step 3: Present the Story

The moderator reads the story aloud and answers questions. Here's the key: no estimation discussion yet. Just clarification.

Step 4: Estimate Privately

Each team member picks a card without showing anyone. This is crucial—it prevents the senior dev's "8" from swaying everyone else before they've thought it through.

Step 5: Reveal Simultaneously

Everyone flips their cards at once. This moment tells you a lot: if estimates are all over the map, you've got different assumptions that need surfacing.

Step 6: Discuss and Re-estimate

When estimates differ significantly:

  • Whoever picked the highest and lowest cards explains their thinking
  • The team discusses approach, risks, dependencies, edge cases
  • Then vote again
  • Usually takes 2-3 rounds max to reach consensus

Step 7: Record and Move On

Once the team agrees, log the estimate and move to the next story. Don't overanalyze—done is better than perfect.

Why Planning Poker Works

It kills anchoring bias. When everyone reveals simultaneously, the senior architect's estimate doesn't sway the junior dev before they've formed their own opinion.

It surfaces hidden assumptions. A developer estimating "3" might be thinking about the happy path, while the tester estimating "13" knows about the edge cases that always break. That gap forces a conversation.

It engages quiet team members. Everyone has to pick a card. The introvert who'd never speak up in a free-form discussion has equal weight here.

It's actually faster. Sounds counterintuitive, but structured estimation beats endless debate. Set a timer, discuss divergent estimates, and move on.

Best Practices for Planning Poker

Set Time Limits

Cap each story at 5-10 minutes. If you haven't reached consensus by then:

  • Go with the most common estimate
  • Park it for more refinement
  • Break it into smaller stories

If a story sparks a 20-minute architecture debate, that's a sign it needs more work before estimation.

Use a Reference Story

Start each session by looking at a completed story everyone remembers. "That login feature we finished last sprint? That was a 5." This calibrates everyone's mental scale.

Think Relative, Not Absolute

Story points measure complexity, not hours. A 5-point story should be roughly 2.5x as complex as a 2-pointer. Don't try to map them to time—velocity will show you throughput naturally.

Include the Whole Team

Get everyone who'll touch the work into the room: developers, testers, designers. Missing perspectives lead to blind spots.

Estimate Often, Not Everything

Don't block off a day to estimate 100 stories. Run quick refinement sessions weekly. Your backlog stays fresh, and you're not guessing about work that's months away.

Common Pitfalls and How to Avoid Them

Averaging Estimates

You get votes of 3, 5, and 8. Someone suggests taking the average—5.3, round to 5, done!

Don't. The whole point is the discussion. Why did someone vote 8 when others saw 3? That's where you learn the tester knows about a gnarly integration, or the backend dev remembers this DB is slow. Average the numbers and you lose the insight.

Converting to Hours

"Okay, so if a story point equals 4 hours, this 5-pointer is 20 hours of work, right?"

Nope. Story points aren't time. They're complexity. A 5-pointer might take different teams 1 day or 1 week depending on experience, tech debt, and interruptions. Track velocity over several sprints—that tells you throughput. Trying to convert points to hours defeats the purpose.

Estimation Fatigue

Three hours into your estimation marathon, someone suggests "let's just call everything a 5 and grab lunch."

Cap sessions at 90 minutes. Use "fast mode" for straightforward stories: if everyone's within one Fibonacci number, accept it without discussion. Save the deep dives for stories where estimates diverge wildly.

Management Pressure

Your VP wants to know when the feature ships, so they're pushing you to convert story points into delivery dates.

Push back gently. Story points are for the team's planning, not executive commitments. Show them historical velocity instead: "We average 25 points per sprint, this feature is 100 points, so roughly 4 sprints—give or take."

Advanced Techniques

Async Planning Poker

Got team members in San Francisco, London, and Sydney? Synchronous estimation is painful. Try this:

  1. Post stories in Slack or your project tool
  2. Give the team 24 hours to submit estimates
  3. Review async—if everyone's close, you're done
  4. Only schedule a call for stories where estimates are all over the place

Works best when your team already has strong shared context. For newer teams, you'll need more face time.

Affinity Estimation for Big Backlogs

Staring down 200 unestimated stories? Don't planning poker them one by one. Use affinity estimation first:

  1. Print stories on cards (or use a digital board)
  2. Sort them into "small," "medium," "large," and "extra large" piles as a team
  3. Then use planning poker to assign specific values to each pile

Knocks out a huge backlog in an afternoon.

Fast Mode

Once your team's been working together a while, you'll develop shared intuition. If everyone votes within one Fibonacci number (say, all 3s and 5s), just pick one and move on. Save the discussion for the outliers.

Tools for Planning Poker

Physical cards work great if everyone's in the same room. For remote teams, you'll need digital tools. Look for:

  • Real-time sync - Everyone sees votes instantly
  • Multiple card decks - Fibonacci, T-shirt sizes, whatever your team uses
  • Timers - Keep discussions from spiraling
  • Issue tracker integration - Pull stories from Jira or Linear directly
  • Guest access - Let your PM observe without needing an account
  • Velocity tracking - See your estimation patterns over time

The best tool is the one your team will actually use. Start simple—even a shared spreadsheet beats analysis paralysis over the "perfect" tool.

Measuring Success

How do you know if planning poker is actually helping? Track these:

Velocity stability - After 3-4 sprints, your velocity should stop bouncing wildly. That's when you can start making reasonable predictions.

Estimate consistency - You're not aiming for perfection. You want to see that a "5" in sprint 1 represents roughly the same complexity as a "5" in sprint 5.

Team confidence - Ask your team: do they feel good about their estimates? Are the discussions surfacing useful insights, or just bikeshedding?

Time spent estimating - As shared understanding grows, estimation should get faster. If you're still spending 15 minutes per story after six months, something's off.

Conclusion

Planning poker won't give you perfect estimates. Nothing will—estimation is hard, and software is unpredictable.

What it will give you is shared understanding. When your frontend dev, backend dev, and QA engineer all agree something's an 8, they've talked through the approach, surfaced the risks, and aligned on what "done" means. That alignment is worth more than the number itself.

Start simple. Follow the basic process. If a story triggers a 20-minute debate, you're learning something—even if you end up parking it for refinement. If your team starts finishing sprints more predictably and arguing less about scope, you're on the right track.

The goal isn't certainty. It's getting everyone looking in the same direction.

Related Articles

Ready to Start Planning?

Put these planning poker techniques into practice with our free tool. Create a session in seconds and start improving your team's estimation process today.