Anchoring before the vote
When someone says "this is probably a three" before voting, the room is no longer estimating independently. People may adjust toward that number even when they see different risks. Keep early discussion focused on facts, questions, and assumptions. Save numbers for the private vote.
Averaging incompatible assumptions
A vote split between 2 and 8 does not mean the answer is 5. It usually means participants are estimating different work. Discuss the assumptions, then vote again. Averaging can hide the very information planning poker is designed to reveal.
Using estimates as commitments
Estimates help planning, sequencing, and trade-off conversations. They should not become personal performance targets. When teams are punished for estimates, they learn to pad numbers, avoid risk, or stop being honest about uncertainty.
Letting seniority decide
Senior voices are valuable, but they should not erase other perspectives. Testing, support, design, product, and operations may notice work that developers do not. If one person's vote always wins automatically, the team is not using planning poker; it is using a slower way to ask that person for a number.
Estimating too many unclear items
Backlog refinement is not a race to attach points to every line. If an item is unclear, mark the question and move it out of the estimation flow. A smaller number of well-understood estimates is more valuable than a long list of guesses.
Changing scales casually
Switching between Fibonacci, ordinal, and decimal scales changes what each card means. Choose a scale deliberately and keep it stable long enough for the team to build shared reference points. Change the deck when the old one no longer supports useful conversations, not because a single vote felt awkward.