One More Point

HomeBlog5 Common Planning Poker Mistakes (And How to Fix Them)
Cover illustration for "5 Common Planning Poker Mistakes (And How to Fix Them)"

5 Common Planning Poker Mistakes (And How to Fix Them)

Fundamentals2 min read

5 Common Planning Poker Mistakes (And How to Fix Them)

Planning poker is simple to run but easy to run badly. These are the mistakes that show up most often, and what to do instead.

1. Treating estimates as commitments

The moment a story point becomes a promise, people stop estimating honestly and start negotiating. Estimates describe relative effort, not a deadline. Keep sprint commitments and story points as separate conversations.

2. Re-using point values across teams

A "5" on one team is not a "5" on another - each team's scale is calibrated to its own velocity and history. Comparing points across teams (or worse, using them for cross-team capacity planning) produces numbers that look precise but mean nothing.

3. Estimating stories that aren't ready

If the acceptance criteria are still being debated, voting on size just produces noise. Park the story, get it refined, and bring it back next session. A fast "not ready yet" is more useful than a confident wrong guess.

4. Letting the loudest voice anchor the room

Whoever speaks first - especially a senior engineer - pulls everyone else's vote toward them. This is anchoring bias, and it's the most common way sessions quietly fail. Simultaneous reveal (cards flipped at the same time, not called out one by one) is the single biggest fix for this. Use a tool like One More Point so nobody sees another vote before casting their own.

5. Skipping re-estimation after big discoveries

Mid-sprint, a team often learns something that changes a story's true size (when to re-estimate is a judgment call). Skipping the re-estimate because "we already pointed it" just means the next planning session inherits a bad number. Flag it, re-vote quickly, and move on.


None of these fixes require new tooling or process overhead - just a bit more discipline about what an estimate actually represents.

FundamentalsHow to Estimate Bug Fixes in Your BacklogBug fixes are notoriously hard to estimate because the scope is often unknown until you're in the code. Here's a framework for sizing them without wild guessing.FundamentalsSplitting User Stories Without Losing Estimation ValueSplitting stories to fit a sprint is easy. Splitting them so the pieces remain independently deliverable and estimable is harder. Here's how to do it right.FundamentalsHow to Know When a Story Is Too Big to EstimateA story that produces a 21 or "infinity" card isn't just large - it's a signal. Here's how to recognize oversized stories and break them down effectively.

Ready to estimate together?

Start a free session and invite your team when you’re ready.