Planning Poker Doesn't Work for Your Team? Try These 5 Controversial Changes

“Planning Poker Is a Waste of Time.” …Or Is It?

You’ve probably heard someone on your team say it out loud (or quietly in a 1:1):

“Planning poker is just performative. We already know what we’re going to build.”

And honestly? For many teams, they’re right.

• Sessions drag on.
• Senior engineers anchor the estimates.
• Story points become a weird performance metric.
• Half the team is zoning out, waiting for the meeting to end.

One survey of 1,000+ agile practitioners found that over 60% felt estimation meetings were “too long” or “low value”. Yet most teams keep doing planning poker the same way and hope it magically improves.

If planning poker feels broken for your team, don’t throw it away. Change the rules.

Below are five controversial changes that will either:

• Make planning poker actually useful, or
• Prove you don’t need it at all.

Both outcomes are wins.

---

1. Stop Estimating Everything: Use the 80/20 Rule

Most teams estimate way too much. That’s the first problem.

The Controversial Move: Only Estimate the Top 20% of Work

You don’t need story points for:

• Trivial tasks (“Add label to button”)
• Obvious chores (“Update config”, “Add monitoring tag”)
• Tiny bugs with clear fixes

Estimate only:

• Complex stories
• Risky stories
• Cross-team or cross-domain stories

Everything else? Default it to a small size.

For example:

• Use one default size for small tasks (e.g., 1 point or 0.5 point).
• Only bring stories to planning poker if someone says, “I’m not confident we understand this.”

Why This Works

1. You cut meeting time by 30–50%.
   If you’re estimating 40 tickets per sprint, you’re doing too much. Trim it to 10–15.
2. You focus discussion where it matters.
   Estimation is a proxy for risk and complexity. So talk about the risky stuff.
3. You avoid weaponizing story points.
   When everything is estimated, velocity becomes a vanity metric. When only meaningful work is estimated, velocity becomes a planning tool.

How to Implement This Next Sprint

• Before planning:
  • Product Owner marks “Needs estimation” on only the top ~15 stories.
  • Default everything else to a small size (e.g., 1 point) in your backlog.
• In the session:
  • Only discuss items flagged as “Needs estimation.”
  • If someone says, “This small thing is actually hairy,” move it into the estimation list.

---

2. Ban Story Points (Temporarily) and Estimate in Time

Yes, this is heresy in some agile circles. But if story points are causing more fights than insights, you have a bigger problem.

The Controversial Move: Switch to Hours/Days for 4–6 Sprints

Not forever. Just long enough to reset how your team thinks.

Why? Because:

• Many teams pretend story points are abstract, but secretly convert them to hours anyway.
• Newer teams get stuck arguing “Is this a 3 or a 5?” instead of “What would make this simpler?”

A Simple Time-Based Model

For a few sprints, try:

• XS = < 2 hours
• S = 2–4 hours
• M = 0.5–1 day
• L = 1–2 days
• XL = > 2 days (split it)

You’re still using relative buckets, but in a language humans actually understand.

What You Gain

• Less cognitive overhead.
  New team members don’t need a lecture on Fibonacci sequences.
• Faster alignment.
  When someone says, “This is at least a day,” others can quickly challenge or agree.
• Better slicing pressure.
  Anything over 2 days gets auto-flagged for splitting.

How to Transition Back (If You Want)

After 4–6 sprints:

• Look at your actual cycle times per size bucket.
• Map them to story points if you still want points:
  • XS → 1
  • S → 2
  • M → 3
  • L → 5
  • XL → split into smaller stories

If your team is more productive arguing less, you might not bother going back.

---

3. Make Planning Poker About Risk, Not Effort

Most teams use planning poker to argue about effort. That’s shallow.

The real value is in surfacing unknowns and risks.

The Controversial Move: Estimate Risk First, Size Second

Before you flip cards for size, ask:
“On a scale of 1–5, how risky is this story?”

Risk includes:

• Unknowns in requirements
• Dependencies on other teams
• Tech you haven’t used before
• Data migrations or side effects

A Simple Two-Step Poker Flow

1. Risk Round

   • Everyone votes risk level 1–5.
   • If there’s a big spread (1 vs 4, 2 vs 5), talk about:
     • “What do you know that I don’t?”
     • “What assumptions are you making?”
   • Capture risks and follow-ups directly in the ticket.

2. Size Round

   • Only after risk is discussed, vote on effort (points/time).
   • You’ll notice estimates converge faster because you’ve aligned on context.

Example in Practice

User story: “Add SSO support for customer tenants.”

• Dev A: Risk 2 — “We’ve done SSO before; this is similar.”
• Dev B: Risk 5 — “Yes, but this tenant uses a custom IdP and weird claims.”
• Result: You uncover:
  • Need for a test environment with the tenant
  • A spike to explore IdP integration
  • A dependency on security review

Now your estimate reflects reality, not blind optimism.

---

4. Let the Quietest Person Speak First (And Keep Votes Anonymous)

If your planning poker feels like “What did the senior dev say? OK, I’ll pick that too,” you’re not estimating — you’re following.

The Controversial Move: Enforce Anonymous, Simultaneous Voting

Anchoring bias is real:

• If one person says “This is easy, maybe 1 point,” others are nudged to agree.
• Junior devs rarely push back on a confident senior.

You need:

• Anonymous voting
• Everyone reveals at the same time
• A rule: no one explains their vote until all cards are visible

How to Make This Work Remotely

Use any tool that supports:

• Hidden votes until reveal
• Quick re-votes after discussion

Then add one more rule:
The outlier speaks first.

• If everyone votes 3 except one person who votes 8:
  • That person explains before anyone else.
  • The goal is not to convince, but to reveal assumptions.

What changes:

• Quiet or junior folks finally get heard.
• You catch edge cases and hidden complexity early.
• The team learns from each other’s mental models.

If your current tool doesn’t support anonymous voting, change tools or change the format. Otherwise, you’re wasting everyone’s time.

---

5. Cut Session Length in Half and Increase Frequency

Most teams try to cram all estimation into a single long meeting. That’s where focus goes to die.

The Controversial Move: 30-Minute Max Sessions, Twice a Week

Attention drops hard after 30–45 minutes. Yet many teams run 90-minute marathons.

Try this instead:

• Two 30-minute sessions per week
• Hard stop at 30 minutes
• Whatever isn’t covered rolls to the next session

Why This Works

• Less fatigue, better estimates.
  When people are mentally done, they stop challenging assumptions.
• Fresher context.
  You can estimate closer to when work will actually be picked up.
• Smoother backlog flow.
  The Product Owner isn’t scrambling to have 3 sprints worth of work ready.

A Sample Weekly Rhythm

• Tuesday 10:00–10:30 — Estimation session 1
• Thursday 10:00–10:30 — Estimation session 2

In each:

• PO brings 5–10 stories max.
• Team estimates until time’s up.
• Anything left is first in line for the next session.

You’ll spend less total time than your current 90-minute slog, and the quality of discussion will go up.

---

Common Mistakes That Make Planning Poker Useless

Before you implement any changes, be honest: are you doing these?

Mistake 1: Using Estimates as Performance Metrics

If leadership is saying:

• “Why did this 3-point story take 3 days?”
• “Team A delivers more points than Team B, what’s wrong with B?”

You’ve already poisoned the well.

What to do instead:

• Communicate clearly upward:
  “Story points are for forecasting, not performance evaluation.”
• Show trends over many sprints, not individual stories.
• If needed, stop using points until the misuse stops.

Mistake 2: Estimating Stories You Don’t Understand

Red flag phrases:

• “We’ll figure it out later.”
• “We don’t know what the API looks like yet, but let’s call it a 5.”

You’re not estimating; you’re guessing.

What to do:

• If you can’t explain the acceptance criteria in 1–2 sentences, don’t estimate.
• Create a spike instead:
  • Time-boxed research (4–8 hours)
  • Clear outcome: “We will know X, Y, Z”
• Estimate the real story after the spike.

Mistake 3: Treating Planning Poker as a Status Meeting

If people are giving updates like:

• “I’m working on X, then I’ll pick up Y…”
• “I haven’t looked at this ticket yet, but…”

You’ve drifted into standup mode.

Fix it by:

• Keeping a strict agenda:
  • Clarify story
  • Estimate risk
  • Estimate size
• Parking anything that sounds like status or solution design for a separate session.

Mistake 4: Inviting Too Many People

If you have:

• 10+ people in the room
• 2–3 actually talking
• 7 silently clicking cards

You’re burning time.

What to do:

• Limit estimation to the people most likely to work on the ticket.
• Rotate participants over time so knowledge spreads.
• Share outcomes in a brief summary or in the ticket comments.

---

Practical Implementation: Turning These Ideas into Your Next Sprint

Here’s a concrete way to experiment without wrecking your current process.

Step 1: Pick Two Changes to Try First

Don’t overhaul everything at once. For the next 2–3 sprints, pick:

• One scope change (e.g., estimate only 20% of stories)
• One format change (e.g., anonymous voting or risk-first)

Agree as a team:

• “We’re running an experiment.”
• “We’ll keep it for 2–3 sprints, then evaluate.”

Step 2: Define What “Better” Looks Like

Make it measurable:

• Estimation meeting time reduced by 30%
• Fewer “surprise” stories that blow up in the sprint
• Higher confidence in sprint commitments (ask the team to rate 1–5)

Capture a quick baseline now, then compare after 2–3 sprints.

Step 3: Adjust Your Backlog Prep

Product Owners need to:

• Pre-mark which stories actually need estimation.
• Ensure acceptance criteria are clear enough to discuss risk.
• Split anything obviously huge before it hits the session.

Step 4: Use a Tool That Doesn’t Get in the Way

You don’t need a heavyweight system. You do need:

• Anonymous voting
• Quick session setup
• Easy linking to your backlog tool

Lightweight tools like ScrumPoi make this painless: no signup, supports anonymous planning poker and retrospectives, and integrates with Jira so you’re not copying things around.

---

Conclusion: Fix the Game, Not Just the Cards

If planning poker feels like a waste, it’s usually not the technique’s fault. It’s the way you’re using it:

• Estimating everything instead of the important things.
• Arguing about numbers instead of risks.
• Letting the loudest voice win instead of surfacing diverse perspectives.
• Running sessions long past the point where anyone is thinking clearly.

You don’t have to accept that as “just how agile works.”

Change the rules:

• Estimate less, talk more about risk.
• Timebox harder, vote anonymously.
• Treat story points as a planning tool, not a performance weapon.

If your team experiments with even two of these controversial changes and nothing improves, you’ve learned something valuable: maybe you don’t need planning poker at all.

But most teams do see improvement — not because they found the perfect number, but because they finally started having the right conversations.