How to Run Planning Poker Sessions That Don't Waste Time

Planning poker should take 15 minutes, not an hour. But most teams turn it into a drawn-out debate where the loudest person wins and everyone else checks out.

After years of running sprint planning sessions (and building my own planning poker tool), I've learned what actually works. Here's the no-fluff version.

The Point of Planning Poker

Before the tactics, let's be clear about what we're trying to achieve.

Planning poker exists to surface disagreements early. When one developer thinks a task is trivial and another thinks it's a week of work, you've found a misunderstanding that would have exploded later.

The goal is not to get a perfect estimate. It's to get everyone aligned on what the work actually involves.

Rule 1: Vote Before You Talk

This is the most important rule, and most teams break it constantly.

Everyone votes simultaneously, then reveals at the same time. No discussion before the reveal. No "well, I was thinking maybe a 5 because..." before cards are shown.

The moment someone speaks first, everyone else anchors to their number. The senior dev says "probably a 3" and suddenly the junior who was thinking 8 second-guesses themselves.

Hidden voting until reveal. Non-negotiable.

Rule 2: Only Discuss When Votes Diverge

If everyone votes 5, move on. You have consensus. There's nothing to discuss.

Only stop to talk when there's significant spread. My rule: if the highest and lowest are more than two Fibonacci steps apart (like a 3 and an 13), that's worth discussing.

The discussion format is simple: highest and lowest explain their reasoning. That's it. Not everyone shares their thought process. Just the outliers.

Usually one of three things happens:

• The high voter knows about a technical complication others missed
• The low voter knows about existing code that makes it easier
• Someone misunderstood the requirement entirely

Ten seconds of explanation, then revote. If you're still divergent after two rounds, take the higher number and move on. Endless debate doesn't produce better estimates.

Rule 3: Timebox Ruthlessly

Set a timer. I use 2 minutes per item maximum, including discussion.

When the timer goes off, you either have consensus or you take the higher estimate. No extensions.

This sounds aggressive, but it works. Teams that timebox strictly estimate 3x more items in the same meeting time. And their estimates aren't any less accurate.

The dirty secret of estimation: spending more time doesn't make estimates better. The information you have in the first 30 seconds is usually the same information you have after 10 minutes of debate.

Rule 4: Keep the Room Small

Planning poker with 12 people is chaos. Planning poker with 4 people is fast.

You need the people who will actually do the work. That's it. Product owner to clarify requirements, developers who will build it. Skip the managers, stakeholders, and "interested parties."

If someone isn't voting, they shouldn't be in the room.

Rule 5: Prepare the Backlog Before the Meeting

Half of planning poker time gets wasted on "wait, what does this ticket actually mean?"

The product owner should review every item before the session. Requirements should be clear. Acceptance criteria should exist. Questions should be answered in the ticket, not live in the meeting.

If a ticket isn't ready to estimate, skip it. Don't waste the room's time figuring out requirements that should have been written down already.

The Scale Doesn't Matter Much

Teams love to debate Fibonacci vs T-shirt sizes vs powers of 2.

Here's the truth: it barely matters. Pick something and stick with it.

Fibonacci (1, 2, 3, 5, 8, 13) works because the gaps get bigger as numbers increase. This matches how uncertainty works. The difference between 1 and 2 points is meaningful. The difference between 13 and 14 is noise.

If your team prefers T-shirts (S, M, L, XL), that's fine too. The scale is just a communication tool.

What matters is consistency. Use the same scale for a few months before you decide it's not working.

Remote Planning Poker

For distributed teams, the fundamentals stay the same. But the tooling matters more.

You need software that enforces hidden voting. If people can see each other's votes before reveal, you'll get anchoring.

You need instant reveal so there's no awkward "okay, on three, everyone say your number" over video chat.

I built ScrumDeck specifically because the tools I tried either required everyone to create accounts (friction) or didn't handle the reveal properly (anchoring).

Whatever tool you use, test it before the meeting. Nothing kills momentum like five minutes of "can everyone see the room?" troubleshooting.

When Planning Poker Isn't the Answer

Planning poker works great for known work types. Feature development. Bug fixes. Technical debt.

It works poorly for research spikes and exploratory work. If you don't know what you're building yet, you can't estimate how long it takes.

For unknowns, timebox the exploration instead. "We'll spend 3 days investigating this, then we'll know enough to estimate the actual work."

The Bottom Line

Good planning poker is fast, focused, and reveals disagreements early.

Keep votes hidden until reveal. Only discuss when there's divergence. Timebox ruthlessly. Keep the room small. Prepare the backlog in advance.

Do these things and your planning sessions will be half as long and twice as useful.