What is Planning Poker and Why Most Teams Get It Completely Wrong

What Is Planning Poker and Why Most Teams Get It Completely Wrong

You’re not “estimating” in Planning Poker.

You’re negotiating a number.

If that stings a bit, you’re not alone. In many teams I coach, Planning Poker is the most ritualized, least useful thing they do in Scrum. It burns time, creates false certainty, and still leaves everyone surprised when work blows up.

And yet, when used properly, Planning Poker is one of the best tools you have for exposing complexity, misalignment, and hidden work.

The problem isn’t the technique.
The problem is how most teams use it.

What Planning Poker Is Really For

Most teams think Planning Poker is about picking the “right” estimate.

It’s not.

Planning Poker is a structured conversation tool that uses relative sizing to:

Expose different mental models in the team
Surface hidden work and risks
Align on scope and approach
Produce good-enough estimates for forecasting

The numbers are a side effect. The conversation is the product.

Quick recap: How Planning Poker works (when done sanely)

The classic flow:

Product Owner explains a user story.
Team asks clarifying questions.
Each estimator privately picks a card (e.g., Fibonacci: 1, 2, 3, 5, 8, 13…).
Everyone reveals at the same time.
People with high and low estimates explain their thinking.
Repeat voting once or twice after discussion.
Move on with the chosen estimate.

That’s it. Simple. But the devil is in how you do each step.

Why Teams Use Planning Poker in the First Place

If you’re going to spend 60–90 minutes every sprint doing this, it should earn its keep.

Done well, Planning Poker helps you:

Spot misunderstandings early
“Wait, you thought QA was out of scope for this story?”
Expose hidden dependencies
“We need DevOps to add a new environment for this. That’s not trivial.”
Calibrate relative complexity
“This story feels like that login story we did last sprint, so it’s probably a 3.”
Create shared ownership
Everyone understands what “done” means and what it will roughly take.

Teams that use Planning Poker well usually see:

Fewer “surprise” stories that explode mid-sprint
Better predictability over a few sprints
Higher-quality conversations about scope and trade-offs

But that’s not what most teams experience.

How Most Teams Get Planning Poker Completely Wrong

Let’s be blunt: most Planning Poker sessions are theater.

Here are the most common failure modes I see across teams and organizations.

1. Treating it like a voting game instead of a thinking process

If your process looks like this:

PO reads title of story
People shrug and pick numbers
You average or “compromise” on a number
Move on quickly to “get through the backlog”

…you’re not estimating. You’re doing consensus theater.

Symptoms:

No one can explain why story X is a 5 and story Y is an 8
Estimation feels like a chore, not a useful discussion
Surprises in implementation are frequent (“We didn’t think of that”)

2. Letting the loudest voice win

This is the classic anchoring problem:

Senior dev says, “This is easy, 2 points.”
Everyone else feels pressure to match, even if they disagree.
Over time, estimates reflect hierarchy, not complexity.

Anchoring bias is real. Studies in behavioral economics show that even arbitrary numbers can influence decisions. In teams, titles and experience become those “anchors.”

If people are changing their estimate because of who spoke, not what was said, your process is broken.

3. Estimating work you don’t understand

You cannot estimate what you have not clarified.

Yet teams routinely estimate stories like:

“Build reporting dashboard”

With no agreement on:

Which metrics?
Which users?
What level of interactivity?
Any performance expectations?

Then they’re shocked when the 5-point story quietly becomes a 13.

If your refinement is weak, your Planning Poker session becomes a guessing game.

4. Using story points as a performance metric

This one is toxic.

If your organization uses:

Velocity to compare teams
Story points to measure individual performance
“More points” as evidence of productivity

…you’ve turned Planning Poker into a political game.

What happens next:

Teams inflate estimates to look “faster”
People resist splitting stories (fewer points!)
The conversation becomes: “How many points can we squeeze out of this?” instead of “What’s the real complexity?”

At that point, your estimates are lies. Everyone knows it, and they behave accordingly.

5. Treating the number as a commitment, not a forecast

Planning Poker gives you a forecast, not a guarantee.

But many teams experience:

“You said this was 3 points. Why isn’t it done?”

So what do people do?

Pad estimates
Avoid calling out risks
Stop being honest when they don’t know

A 5-point story isn’t a promise. It’s a shared guess based on current knowledge.

6. Estimating everything, including the trivial and the unknown

Two extremes I see all the time:

Estimating tiny, obvious tasks (“Add a label to a button” – 1 or 2? Who cares.)
Forcing estimates on big, fuzzy, high-uncertainty work (“Rebuild the billing system”)

In both cases, Planning Poker is wasted:

For tiny tasks, the overhead isn’t worth the conversation.
For huge unknowns, you’re roleplaying certainty you don’t have.

What Planning Poker Should Look Like

Let’s flip the script.

Here’s what a healthy Planning Poker practice actually looks like.

1. The conversation is the goal, not the number

When the cards flip and you see 2, 3, 8, and 13, your first reaction shouldn’t be:

“Okay, let’s average that to 5.”

It should be:

“Interesting. Why such a spread? What are you seeing that I’m not?”

Use the disagreement as a signal:

The 2 thinks it’s just UI work.
The 13 knows there’s a gnarly integration with a legacy API.
The 8 is worried about performance testing.

Now you’re uncovering reality. That’s the point.

2. Use a clear “definition of done” for estimation

Estimating without a shared Definition of Done is like measuring distance without agreeing where the finish line is.

Before you flip any cards, everyone should know what “done” includes:

Coding
Code review
Tests (unit/integration/automated)
Documentation
Deployment
Feature flagging / rollout

When this is explicit, your estimates become more consistent and your conversations sharper.

3. Estimate relatively, not absolutely

Stop asking, “How many hours is this?”

Ask instead:

“Compared to our baseline story (say, a 3-pointer we all know), is this:

About the same?

Half as complex?

2–3x more complex?”

Relative sizing is the whole point of Planning Poker. Humans are terrible at absolute prediction but much better at comparison.

4. Focus on risks, unknowns, and constraints

When people explain their estimate, guide them:

“What risks are you accounting for?”
“What unknowns make you go higher?”
“What assumptions are you making?”

You’re not just sizing work. You’re mapping risk and uncertainty.

Example:

“I picked 8 because:

We don’t know how flaky the third-party API is.

We’ve never integrated with this vendor before.

We might need to refactor the auth layer.”

That’s gold. Now the team can:

Spike the integration first
Talk to the vendor
Timebox an experiment

Common Planning Poker Mistakes (and How to Fix Them)

Here’s a more tactical breakdown of what not to do—and what to do instead.

Mistake 1: Estimating in giant, rushed sessions

Symptoms:

2–3 hour meetings
People mentally checking out
Rushing through the last 10 stories

Fix it:

Do shorter, more frequent refinement sessions (e.g., 45–60 minutes, twice a week)
Limit how many stories you estimate at once (e.g., just enough for the next sprint or two)
Stop the session when the energy drops; bad estimates come from tired brains

Mistake 2: Letting the PO or manager influence numbers

If your PO or manager is saying:

“This should be a 2, it’s not that big.”

You’ve already lost.

Fix it:

Make it explicit: only the delivery team estimates
PO explains the “what” and “why,” team estimates the “how”
If someone with authority can’t resist pushing numbers, have them step out during voting

Mistake 3: Not using anonymous voting

If people are changing their estimate after seeing the first card flipped, you’re not getting honest input.

Fix it:

Use tools or physical cards that reveal simultaneously
If you’re remote, use tools that support anonymous voting until reveal
Only discuss estimates after everyone has committed

This alone dramatically reduces anchoring and groupthink.

Mistake 4: Re-voting endlessly until everyone agrees

If you’re doing 4–5 rounds of re-voting to “get to consensus,” you’re wasting time.

Fix it:

After 1–2 rounds, if you’re still split, do one of:
- Pick the higher estimate and move on (acknowledge uncertainty)
- Split the story into clearer, smaller chunks and re-estimate later
- Timebox a spike and estimate again once you know more

The goal is good-enough alignment, not perfect agreement.

Mistake 5: Estimating work that shouldn’t be estimated

Not all work needs Planning Poker.

Fix it:

Don’t estimate:
- Tiny chores and obvious tasks
- One-off support tickets
- Operational overhead (meetings, admin, etc.)
Use a simple policy like:
- Only estimate stories that:
  - Affect users or systems meaningfully, and
  - Have enough uncertainty to warrant discussion

Practical, Actionable Steps to Fix Your Planning Poker

If you recognize your team in any of this, here’s a concrete way to reset.

Step 1: Reset expectations with the team

Have a candid conversation:

“We’ve been treating Planning Poker like a number-picking game.”
“From now on, we care more about the conversation than the number.”
“We’ll optimize for surfacing risks, unknowns, and misunderstandings.”

Make it explicit that:

Estimates are forecasts, not commitments.
Velocity is for the team, not for comparing or judging individuals.

Before you estimate a story, ensure:

It has a clear user-facing goal
Acceptance criteria are written and understood
Dependencies are at least identified
It’s small enough to complete within a sprint

If those aren’t true, don’t estimate yet. Refine first.

Step 3: Use a consistent scale and baseline stories

Pick a scale and stick to it (e.g., Fibonacci: 1, 2, 3, 5, 8, 13, 21).

Then:

Choose 2–3 “reference stories” your team knows well:
- A typical 3: small feature with some logic and tests
- A typical 5: multi-step change with integration and testing
- A typical 8: complex change with risk or uncertainty

When estimating, compare to those instead of guessing blindly.

Step 4: Enforce silent, simultaneous voting

Whether you’re using physical cards or an online tool:

Everyone picks privately
No one talks about numbers before the reveal
After reveal, only the outliers explain first (lowest and highest)

This keeps the discussion focused and reduces dominance effects.

Step 5: Timebox estimation discussions

Don’t let one story hijack the session.

Timebox each story’s estimation discussion (e.g., 5–7 minutes)
If you’re still confused:
- Mark it as “needs spike” or “needs refinement”
- Move on and don’t force an estimate

This protects the team’s energy and prioritizes clarity over fake precision.

Step 6: Regularly inspect and adapt your approach

Every few sprints, ask:

Are we surprised by how often estimates are off?
Are we discovering fewer “unknown unknowns” during implementation?
Does the team feel Planning Poker is valuable or just overhead?

Use a retrospective to adjust:

The stories you choose to estimate
The scale you use
How often and how long you estimate

Planning Poker is a tool. Tune it like one.

Tools That Help (Without Taking Over)

You don’t need fancy software to do Planning Poker, but a decent tool helps, especially for remote teams:

Look for:

Anonymous voting until reveal (to reduce anchoring)
Easy story import from your backlog tool (e.g., Jira)
No heavy setup or logins for guests
Support for both estimation and retrospectives in one place

Tools like ScrumPoi, for example, keep it simple: no per-user costs, anonymous voting, quick sessions without signup, and Jira integration so you’re not copy-pasting story titles all day.

Planning Poker Isn’t the Problem. How You Use It Is.

If Planning Poker feels like a waste of time in your team, it’s not because:

“Story points don’t work”
“Estimation is useless”
“Agile is broken”

It’s usually because:

You’re chasing numbers instead of insight
You’re using it as a performance tool instead of a learning tool
You’re estimating work you don’t understand and then pretending you do

Used well, Planning Poker:

Forces real conversations about risk and complexity
Aligns the team on what “done” actually means
Gives you just enough predictability to plan sanely

If it’s not doing that for you, don’t throw it out. Fix it.

Start with one change:
Next session, when the cards flip and the numbers don’t match, resist the urge to average.

Ask:
“What do you see that I don’t?”

That question is worth more than any number on the card.

What is Planning Poker and Why Most Teams Get It Completely Wrong