Mistake 1: voting before the story is understood
A planning poker vote is only useful after the team understands the item well enough to compare it with other work. If people are asking what the user actually needs, which system is touched, or what done means, the room is not ready to estimate. Spend a few minutes sharpening the story first. If the basics still do not hold, send it back to refinement.
Mistake 2: letting a senior voice anchor the room
The fastest way to flatten a planning poker session is to let one confident person state the number first. Everyone else then has to argue against that anchor, even if the first number was just a guess. Hidden voting protects quieter information. Reveal first, then ask the high and low voters to explain what they saw.
Mistake 3: treating the estimate as the decision
The estimate is not the whole planning decision. A low estimate can still be risky if the team has a hard dependency or very little capacity. A high estimate may be acceptable if the work unlocks something important. Use the number as input, then decide whether to split, refine, schedule, or defer.
Mistake 4: forcing consensus when the story is too large
Wide disagreement is not a facilitation failure. Sometimes it is the signal the team needed. If the spread stays wide after one short discussion, stop trying to negotiate the room into a single number. Split the story, identify the unknown, or capture the decision needed from product or architecture before voting again.