Ten planning poker mistakes, and how to avoid them

28 October 2026 · 8 min read

Planning poker looks hard to get wrong: pick a card, flip it, talk. Yet plenty of teams play it every sprint and still miss their plans, sit through hour-long sessions and watch half the room stop paying attention. The method usually isn't the problem. A handful of habits are, and most of them start out as shortcuts. Here are ten we see most often, how to spot each one, and what to do instead.

The ten mistakes at a glance

1. Voting on stories that aren't ready

A story with no acceptance criteria, an unknown dependency or a fuzzy definition of done can't be sized, only guessed. Everyone fills the gaps with their own assumptions, so the votes scatter from 1 to 21, and even when the team settles on a number it means nothing.

Fix it: agree on a short definition of ready (what the story should do, how you'll know it's done, what it depends on) and check stories against it before the session. Have the product owner in the room to answer questions. When a reveal shows a spread like that anyway, stop voting: give the open question an owner and park the story. Decks have a card for "I can't size this" (🙈 or ?) so nobody has to invent a number.

2. Leaking a number before the reveal

The whole point of hidden votes is to stop anchoring: once someone hears a number, their own estimate drifts toward it. Teams undo this without noticing. The tech lead thinks aloud ("this is just a config change"), someone asks "so, a 3?", or a senior developer picks first and everyone watches their face.

Fix it: make it a house rule that nobody says a size, or anything that sounds like one, until the cards are flipped. Questions about the work are fine; verdicts on its size wait. If people still defer to seniority, use an anonymous room, where the reveal shows how many people picked each card but not who picked what.

3. Averaging away the disagreement

The cards show 3, 3, 3, 5 and 13, and someone says "call it a 5". It feels efficient, but it throws away the most useful thing the round produced. The person who voted 13 may know about the flaky sandbox, the legacy module or the migration nobody mentioned. Or they misread the story, which takes thirty seconds to fix. Either way, the team needed that conversation.

Fix it: when the votes diverge, the highest and lowest voters speak first, briefly, then the team revotes once. The aim is a shared picture of the work, not matching cards. Our guide to reading a reveal covers the six shapes a spread can take and what each one asks of you.

4. Arguing between neighbours

The opposite mistake is just as common. Three people vote 5 and two vote 8, and the team spends five minutes deciding which. Neighbouring cards on a Fibonacci-style deck are closer together than any estimate is accurate, so the debate buys nothing and drains the energy you'll need for the stories that really are split.

Fix it: adopt the one-step rule. If every vote sits within one step of the others, take the card at or just above the average and move on. That is also what Estimay saves on its own when the cards are revealed, and the host can change it in one click if the room decides otherwise.

5. Estimating hours in disguise

Story points are meant to compare stories with each other: this one is about twice the size of that one. As soon as a team agrees that "a point is half a day", points become hours with extra steps, and the usual problems with hours come back: optimism, padding, and arguments about who is faster.

Fix it: keep two or three reference stories the whole team remembers (a small, a medium, a large) and size new work against them. Speed then belongs to velocity, measured after the sprint, not to the estimate. Our guide to story points walks through picking reference stories.

6. Treating estimates as promises

When estimates are used to judge people ("you said 3, why did it take a week?"), the team learns to protect itself. Estimates creep up, nobody admits uncertainty, and the numbers stop telling anyone anything. Comparing velocity between teams does the same damage, since each team has its own scale.

Fix it: describe estimates as forecasts made with what the team knows today. Re-estimate when you learn something new, and treat that as normal rather than as a failure. Talk about what the team will deliver as a range, never as a promise built from single numbers.

7. One number for three kinds of work

A story needs frontend work, backend work and a fair amount of testing. The developers vote on the part they know, the one tester's card disappears into the spread, and the testing effort turns up halfway through the sprint. A single number can hide work that only one person in the room can see.

Fix it: ask "what does testing this involve?" before every vote, or, when disciplines really differ, estimate each one separately. Estimay can split a story into disciplines (frontend, backend, QA or whatever your team uses), vote on each and add up the story's total.

8. No onboarding for new players

Teams often bring someone new into planning poker without explaining it: why the cards skip numbers, what a point means in this team, what the 🙈 card is for. The newcomer then votes at random or copies whoever looks confident, and the team's scale drifts a little with every new joiner.

Fix it: before their first real session, run a short calibration round on stories the team has already finished, so they can see how the team sizes things. Share a primer on how planning poker works, and revisit the basics whenever the team changes a lot.

9. Never looking back

Estimates that are never compared with reality never get better. If database migrations overrun every sprint, the team should know that before it estimates the next one.

Fix it: once in a while, in a retrospective, take three or four finished stories and ask whether the estimate held, and if not, what the team missed. Don't hunt for blame; look for patterns. Keep the estimates where you can find them later: write them back to your tracker, or download them as a CSV before the room ends.

10. Sessions that run too long

After an hour, attention drops. The last ten stories all get a 3 because nobody has the energy to disagree. That doesn't mean the team agrees; it means the team wants to leave.

Fix it: timebox each story (two to five minutes of discussion is plenty for most), take a break when the answers get short, and stop when the time is up rather than rushing the rest. Small, clear stories don't need a meeting at all: an async room lets people vote in their own time, and the session can focus on the stories that need a conversation. Our guide to timeboxing has a minute-by-minute budget.

A checklist for your next session

• Every story on the list passed the definition of ready.
• The product owner is in the room, or answers questions in the chat.
• Nobody says a size before the reveal.
• Wide spreads: highest and lowest voters speak first, then one revote.
• Votes within one step: take the card at or just above the average, and move on.
• Testing and other hidden work are asked about before each vote.
• Each story has a timebox, and the session has an end time.
• The estimates are saved somewhere the team will see them again.

Try it in Estimay

Estimay is free planning poker that makes most of these habits easy: votes stay hidden until a countdown reveals them all at once, anonymous rooms hide who voted what, the discussion timer counts down for everyone, stories can be split by discipline, and async rooms take the small stories out of the meeting. There's no sign-up, so a new teammate joins from the link.

← All articles