Guide · 7 min read · Updated 2026-09-14
9 Planning Poker mistakes that wreck your estimates
Most teams do not abandon Planning Poker because it fails. They abandon it because a handful of small habits turn a ten-minute conversation into an hour of arguing about numbers nobody trusts. Here are the ones worth fixing first.
1. Someone says a number before the vote
"This is probably a five, right?" — and the round is over before it started. Anchoring is the single most damaging habit in estimation, because it is invisible: the team still votes, the votes still agree, and the agreement means nothing.
The fix is procedural, not cultural. Read the story, answer clarifying questions only, and vote with hidden cards. Anyone who names a value out loud before the reveal forfeits that round — say it once as a rule and it stops happening.
2. Estimating effort in hours wearing points clothing
If your team translates "5" into "about two and a half days" every time, you are estimating hours with extra steps, and you inherit every problem points were meant to avoid: the fastest developer's day is not the newest joiner's day, and neither includes review, testing or the interruption that arrives on Thursday.
Points describe relative size — complexity, uncertainty and volume together. Keep a reference story on screen and ask "bigger or smaller than this?" instead of "how long?".
3. Averaging the votes instead of discussing them
A 3 and a 13 average to 8, and 8 is the one answer that is definitely wrong: it discards the information that two people are looking at completely different pieces of work. The spread is the value of the exercise. The number is a by-product.
When votes diverge, ask the lowest and the highest voter to explain — in that order, so the low voter is not talked out of a genuinely simple approach — then re-vote once.
4. Letting the loudest voice close the round
Estimation is a sampling exercise: it works because several people with different knowledge look at the same problem. If the tech lead's number always wins, you have a one-person estimate with witnesses.
- Have the most senior person reveal their reasoning last, not first.
- Ask the person who will most likely pick up the story to speak first.
- Watch for people who always vote the same as the previous speaker — invite them explicitly.
5. Debating past the point of usefulness
Two people arguing 5 versus 8 for six minutes are arguing about a difference that will not change the sprint plan. Two people arguing 3 versus 21 have found a genuine misunderstanding and should keep going.
A timer per round is the cheapest guard rail there is. Two minutes to vote, three minutes to discuss, and if the second vote still splits by more than one step, take the higher value and move on — or split the story.
6. Estimating stories nobody has refined
You cannot size work whose outcome is undefined. If the room's first question is "what does done mean here?", the story is not ready and the estimate you produce will be a guess that the sprint plan treats as a commitment.
Park it, note the missing decision and the person who owns it, and continue. Sessions where two items get parked are healthier than sessions where everything gets a number.
7. Giving big stories a big number instead of splitting them
A 21 is not an estimate, it is a warning. Anything that large contains work nobody has thought about yet, and its error bar is wider than several small stories combined.
Split by workflow step, by data type, by happy path versus edge cases, or by "make it work" versus "make it good". Two 8s you understand beat one 21 you do not.
8. Comparing velocity between teams
Points are calibrated inside one team against that team's own reference stories. Team A's 5 and Team B's 5 have no relationship whatsoever, so any dashboard ranking teams by points measures scale inflation, not productivity — and teams respond to it by inflating.
Compare a team to its own trend across several sprints and nothing else. See measuring team velocity for what the number can and cannot tell you.
9. Never revisiting the scale
Reference stories age. The team learns the codebase, tooling improves, people join and leave, and the story that was a 5 last year is a 2 today. If you never re-anchor, the scale drifts and your history quietly stops meaning what it did.
Every quarter, or after any significant change in team composition, pick a recently finished story, agree its value together, and use it as the anchor for the next sessions.
A short checklist for the next session
- Reference story visible before the first vote.
- No numbers spoken before the reveal.
- Timer on, one re-vote maximum per story.
- Lowest and highest voters explain, seniors last.
- Anything at 21 or above gets split, not estimated.
- Unrefined stories get parked with a named owner.
Planner Poker enforces most of this by default: cards stay hidden until everyone has voted, the spread and average appear together at the reveal, the round timer is one click away, and the session summary records every participant's vote so you can see who was consistently anchoring or abstaining.