Planning Poker is Broken: Here's How to Actually Make it Work in 2025

Planning Poker is Broken: Here’s How to Actually Make it Work in 2025

Planning Poker is popular in teams. That doesn’t mean it’s done right.

You’ve probably seen this movie:

A 1-hour “estimation meeting” that somehow takes 2 hours
Half the team is silent, one person dominates
Everyone reveals their cards… and then just agrees with the loudest voice
Story points feel random, and nobody trusts them anyway

Yet, the calendar invite keeps recurring because “that’s what Scrum teams do.”

Here’s the truth: Planning Poker isn’t the problem. The way most teams use it is.

If you’re going to invest team time in estimation, it should:

Improve shared understanding
Expose risks and unknowns
Help you make better trade-offs

If it’s not doing those three things, it’s just performative ceremony.

Let’s fix that.

Why Planning Poker Feels Pointless (But Doesn’t Have to Be)

The Original Idea Was Good

Planning Poker was designed to:

Avoid anchoring bias (everyone reveals at once)
Encourage conversation about complexity and risk
Build a relative scale of effort, not precise predictions

When used well, it’s a fast way to spot:

Stories that are under-specified
Hidden complexity (“Oh, but we also need to handle X edge case…”)
Misaligned assumptions across the team

The problem is: teams turned a thinking tool into a ritual.

How It Went Off the Rails

Here’s what I see over and over as a coach:

Teams equate “Planning Poker” with “we must estimate every single ticket”
Story points become a performance metric, not a planning tool
Estimation is used to enforce deadlines, not explore uncertainty

A 2022 study by the State of Agile report showed that over 60% of teams use story points, but a huge portion of them still miss their forecasts regularly. Not because story points are bad—but because the conversations behind them are shallow or rushed.

If Planning Poker doesn’t change decisions (what to do, what to cut, what to split), it’s just noise.

The Real Problems With How Teams Use Planning Poker

1. Treating Story Points Like Hours

Here’s the truth: if your team says things like:

“8 points = 1 day of work”
“We did 40 points last sprint, so we must do 40 again”

…you’ve already lost the plot.

Story points are supposed to represent relative complexity, risk, and effort, not time. When you turn them into hours, you:

Reintroduce all the stress and gaming of time estimates
Punish work on technical debt or refactoring (which is harder to estimate)
Encourage people to pad or under-estimate to “look productive”

2. Using Planning Poker as a Performance Tool

The problem is: many managers (and some product owners) quietly use story points to judge productivity:

“Why did this team only do 20 points?”
“Why is this senior engineer estimating 5 when others say 3?”

Once people know they’re being judged on points, estimation becomes:

Political
Defensive
Inaccurate

You don’t get better estimates; you get safer estimates.

3. Estimating Everything

If you’re doing Planning Poker on:

Tiny bugs
Trivial copy changes
Obvious tasks

…you’re wasting time.

Not everything needs a card. In fact, most things don’t.

A good rule of thumb: if the conversation will be, “Yeah, that’s small,” skip the cards and just mark it as “small.”

4. No Shared Baseline

Another common failure: nobody agrees what “3 points” actually means.

One person thinks:

3 points = “I can do this in half a day”

Another thinks:

3 points = “Simple, but with a couple of unknowns”

Without calibration, Planning Poker turns into:

“I say 3.”
“I say 5.”
“Eh, let’s just go with 5.”

That’s not conversation. That’s compromise without understanding.

5. Letting the Loudest Voice Win

You’ve seen this:

Cards are revealed: 3, 3, 3, 13
Someone says: “13? That’s crazy, it’s just a simple API change.”
The 13 quietly backs down to 5 or 3

What just happened?

A potential risk or hidden complexity got suppressed
Psychological safety took a hit
The team learned: “Don’t be the outlier”

Over time, people stop voting their true opinion and just follow the group.

Common Mistakes: What Not to Do in 2025

If you recognize your team in this list, you’re not alone.

Don’t #1: Use Planning Poker to Justify Deadlines

If your product owner is saying:

“We need this by next Friday, so please estimate it as 3 or less”

…that’s not estimation. That’s negotiation under pressure.

Use estimates to inform deadlines, not to rationalize them.

Don’t #2: Turn It Into a Status Meeting

Planning Poker is not:

“Let’s go through the board and talk about each ticket”
“Let’s discuss why last sprint was slow”

It’s about future work and shared understanding, not rehashing the past.

Don’t #3: Force Consensus on Every Number

If you’re spending 15 minutes debating whether a story is a 5 or an 8, you’re burning time.

Some differences matter (2 vs 13). Some don’t (5 vs 8). Know which is which.

Don’t #4: Estimate Work You Don’t Understand

If your refinement looks like:

“We don’t really know what this is… let’s just call it a 13”

…you’re faking certainty.

When the team doesn’t understand the story, don’t estimate it. Split it, spike it, or clarify it first.

How to Make Planning Poker Actually Useful in 2025

Here’s the truth: you don’t need to abandon Planning Poker. You need to upgrade how you use it.

1. Start With Outcomes, Not Numbers

Before you ever flip a card, ask:

What decision are we trying to make with these estimates?
- Scope trade-offs?
- Release planning?
- Capacity planning?

If you can’t answer that, you’re estimating for the sake of it.

Tactical move:

At the start of the session, the facilitator says:
- “We’re estimating today to decide what fits into the next 2 sprints and to spot risky stories early.”

This frames the whole session around decisions, not just numbers.

2. Estimate Only What Matters

Stop estimating everything. Focus on:

New features
Risky or complex changes
Stories that impact planning or sequencing

Use a simple rule:

No points for trivial work (e.g., “typo fix”, “change label text”)
Default small size (e.g., “1 point”) for routine, low-risk tasks
Planning Poker only when:
- There are visible unknowns
- The team disagrees on complexity
- It’s important for forecasting

This alone can cut your estimation time in half.

3. Calibrate Your Scale With Real Examples

Don’t use abstract definitions. Use actual past stories.

Run a quick calibration exercise:

Pick 5–8 completed stories from the last 2–3 sprints
As a team, assign them to your scale:
- “This is our 1-point reference”
- “This is our 3-point reference”
- “This is our 5-point reference”
Capture them somewhere visible (Confluence, Miro, etc.)

Now, when there’s a debate, you can say:

“Is this more like our ‘3-point login validation’ or our ‘5-point profile refactor’?”

Calibration makes estimation faster and more consistent.

4. Use Disagreement as a Signal, Not a Problem

The most valuable part of Planning Poker isn’t when everyone agrees. It’s when they don’t.

When the spread is big (e.g., 2 vs 13), don’t rush to compromise. Ask:

“What assumptions are you making?”
“What are you worried about?”
“What do you know that others might not?”

Make it safe to be the outlier:

The facilitator should explicitly invite the highest and lowest to speak first
The goal is not to defend a number, but to share perspective

Often, the “crazy” 13 is the person who remembers:

“We tried something like this last year and hit a data migration nightmare.”

That’s the conversation you’re paying for.

5. Timebox Ruthlessly

Long estimation meetings kill morale.

Practical approach:

Timebox each story’s discussion to 5 minutes
If you hit the timebox and still don’t agree:
- Option A: Mark as “Needs Spike” and create a timeboxed spike story
- Option B: Take the higher estimate and move on

This keeps the session focused and prevents rabbit holes.

6. Separate Estimation From Commitment

The problem is: teams often treat estimates as promises.

Fix that by:

Treating estimates as probabilistic, not guaranteed
Using historical throughput (how many stories you actually complete) alongside points
Regularly comparing:
- Estimated vs. actual complexity
- Not to blame, but to refine your shared understanding

Make it clear in your language:

“We forecast this might fit in the sprint,” not “We commit to 40 points.”

7. Use Tech to Reduce Bias and Friction

Anchoring bias is real. If one person says “This is easy” before voting, the numbers skew low.

Use tools or techniques that:

Hide votes until everyone has chosen
Make it easy for remote or hybrid teams to participate
Allow quick re-votes after discussion

Even a basic online tool with anonymous voting and “reveal all” can dramatically improve the quality of your estimates.

A Concrete Example: Fixing a Broken Session

Let’s walk through a before/after.

Before

90-minute meeting
Every ticket in the backlog is estimated
One senior engineer talks first every time
Half the team doesn’t speak
No calibration; people argue 3 vs 5 endlessly
Outcome: a list of numbers nobody trusts

After (Improved Process)

Prep (10 minutes before meeting)
- PO and tech lead pre-select 10–15 stories that:
  - Are likely for the next 1–2 sprints
  - Have some uncertainty or impact
Kickoff (2 minutes)
- Facilitator: “Goal today: estimate enough stories to plan the next sprint and surface risky work. We’ll timebox to 5 minutes per story.”
Calibration (5 minutes)
- Show 3 past stories:
  - “This login bug was our 1-point reference.”
  - “This new settings page was our 3-point reference.”
  - “This data migration was our 8-point reference.”
Estimation Flow (45–60 minutes)
For each story:
- PO gives 1–2 sentence summary and acceptance criteria
- Silent questions in chat or quick clarifications
- Everyone votes simultaneously (cards or tool)
- If spread is small (3, 3, 5): take the median and move on
- If spread is large (2, 13):
  - Lowest and highest explain their thinking
  - One quick re-vote
  - If still wide: either spike it or take the higher estimate
Wrap-up (5 minutes)
- Confirm: “We have enough estimated work for the next sprint plus buffer.”
- Capture any spikes or follow-ups

Outcome: tighter meeting, better conversations, clearer risks.

Tools and Implementation: Don’t Let the Tool Drive the Process

A tool won’t fix a broken estimation culture, but it can support a good one.

Look for tools that:

Support anonymous voting to reduce anchoring
Don’t require complex setup or logins for quick sessions
Integrate with your existing workflow (Jira, etc.)

For example, teams I’ve worked with like using ScrumPoi, a free planning poker and retrospective tool, because it supports anonymous voting, Jira integration, and quick, no-signup sessions—making it easier to focus on the conversation instead of wrestling with the tooling.

The Bottom Line: Planning Poker Is a Means, Not an End

Here’s the truth: Planning Poker should earn its place on your calendar.

If it’s not:

Improving shared understanding
Revealing unknowns and risks
Helping you make smarter planning decisions

…then either fix it or drop it.

In 2025, the teams that win aren’t the ones with the prettiest burndown charts. They’re the ones who:

Use estimation as a learning tool
Make risks visible early
Spend less time guessing and more time delivering

Planning Poker can help you do that—if you stop treating it like a ritual and start treating it like a conversation.

Planning Poker is Broken: Here's How to Actually Make it Work in 2025