Planning Poker Mistakes

Anchoring is the single most damaging thing that happens in estimation sessions, and it is almost always accidental. Someone says “this is probably a 5” while the story is being read, and the subsequent votes cluster around 5 regardless of what anyone independently thought. The effect is strongest when the first number comes from the most senior person in the room, which is also when it is least likely to be challenged. The fix: vote before discussing. Simultaneous reveal exists precisely for this, and it only works if nobody names a number beforehand — including in the story description, the ticket, or the chat.

When the team votes 3, 5 and 13, taking the mean produces 7 — a number that is not on the scale, that nobody voted for, and that nobody believes. Worse, it makes the disagreement disappear, and the disagreement was the valuable part. The fix: treat a wide spread as a signal to talk, not a number to smooth. Ask the highest and lowest to explain, then re-vote. If two adjacent values remain in contention after that, take the higher one.

The moment a team decides that one point equals a day, story points have become hours with extra ceremony. Every benefit — the abstraction from individual speed, the focus on complexity, the honest imprecision at the top of the scale — is gone. This usually creeps in through a well-meaning attempt to make points legible to stakeholders. The fix: if stakeholders need dates, give them dates derived from velocity over several sprints. That is a forecast with uncertainty built in, which is exactly what a point-to-hours conversion destroys.

A team asked to estimate a one-line title with no acceptance criteria will produce a number, because it has been asked to. The number is noise, and it will be used for planning anyway. The fix: a Definition of Ready, and the willingness to send stories back. A question-mark card on the deck helps — it gives people a way to say “I cannot estimate this” that is not a number.

Combining the two meetings sounds efficient and reliably produces both a long meeting and bad estimates. People are being asked to understand new work and commit to delivering it in the same breath, under time pressure, with the sprint boundary approaching. The fix: refine and estimate mid-sprint, when there is no commitment attached and the conversation can be unhurried. Arrive at planning with a sized backlog.

When a manager, stakeholder or product owner votes, their number carries authority the scale was never meant to include. It anchors harder than anyone else's, and people adjust toward it without noticing. The fix: only the people who will do the work vote. Everyone else attends as an observer — present to answer questions, excluded from the count. Spectator mode makes this explicit rather than a social convention people forget under pressure.

A story estimated at 3 turns out to be a 13. The temptation is to update the number so the sprint report looks coherent. Doing so erases the only record that the estimate was wrong, which is the record you would need to get better. The fix: leave the estimate alone and note what was missed. If the scope genuinely changed rather than the estimate being wrong, that is a new story, not a bigger old one.

Twenty minutes spent deciding whether something is a 13 or a 21 is twenty minutes spent on a distinction that will not survive contact with the work. At that size the estimate is a magnitude, not a measurement. The fix: timebox each story — two minutes is plenty for most — and treat anything above 13 as a prompt to split rather than a number to refine.

Team A averages 50 points a sprint, team B averages 30, and someone builds a slide. The comparison is meaningless: the two teams calibrated their scales independently, so the units are not the same units. The damage is not just a bad slide. Once teams understand they are being compared, their estimates inflate, and every team's velocity becomes unusable for its actual purpose. The fix: use velocity only within a team, and only for forecasting. If you need cross-team comparison, measure outcomes or cycle time — things that are denominated in the same units everywhere.

Teams get faster, tooling improves, and a part of the system that was unfamiliar becomes routine. Without periodic recalibration, a “3” slowly comes to mean less work than it used to, velocity trends upward, and everyone congratulates themselves on an improvement that did not happen. The fix: re-anchor against reference stories every few months, and be suspicious of any velocity line that only goes up.

If missing an estimate has consequences, estimates stop being predictions. They become negotiations, and they will be padded — not dishonestly, but by the entirely rational instinct to protect yourself. The fix: this one is organisational rather than procedural. Forecasts need to be revisable without blame, or the numbers will be worthless regardless of how well the sessions are run.

Not all work benefits from being sized. A backlog item nobody will start for six months will be re-refined before it is built, and the estimate will be thrown away. Sizing the entire backlog produces a great deal of documentation about work that will be reprioritised. The fix: estimate roughly two sprints ahead in detail and leave the rest at epic or T-shirt granularity until it comes into view. Estimation is a cost, and like any cost it should be spent where it changes a decision.