Planning Poker mistakes

tl;dr

Most failed Planning Poker sessions trace back to four things: bad refinement, weaponized velocity, anchored discussion, and treating points as hours. The ritual handles a lot on its own — provided someone in the room is paying attention.

In the room: voting & reveal mistakes

Estimating in hours

The team starts converging on hour-equivalents — 3 = half a day, 5 = a day, 8 = a couple of days. Once that mapping shows up, you're doing time-based estimation with a Fibonacci coat of paint, and you've thrown away the relative-effort property the technique exists to give you.

Re-anchor on the reference story and ban hour-talk for one round. If the team can't have the conversation without translating to time, the issue is upstream — usually a stakeholder who only believes in dates.

Just averaging the cards

Someone plays a 3, someone plays a 13, the facilitator splits the difference at 8 and moves on. The whole point of the simultaneous reveal was to surface the disagreement; the average buries it.

When the spread is one step (3s and 5s), take the higher number — that's not averaging, that's defaulting to the more cautious read. When the spread is two steps or more, you have a conversation, not an arithmetic problem.

The senior person's number always wins

Hidden cards stop the lead engineer from anchoring the vote — but they don't stop the lead engineer from ending the discussion. After the reveal, whoever speaks first with confidence still tends to win the room.

Ask the lowest card to explain first, then the highest, then everyone else. Junior voices that anchor the discussion early get to keep their context instead of folding to seniority.

Re-voting until everyone gives up

By the third or fourth re-vote, the spread is narrowing because people are tired, not because they've reached agreement. The estimate that comes out is socially negotiated, not actually shared.

Two votes per story is the right ceiling. If you're heading for a third, the story isn't ready — split it, send it back to refinement, or punt. (See the four-phase loop for the full sequence.)

Ignoring the ? card

Someone plays a ? and the team treats it as a non-vote — "okay, anyone with a real number?" — instead of a stop sign.

A ? is real information: someone in the room can't responsibly size this. That usually means the story is missing context the rest of the team has, or it isn't defined enough yet. Surface it. The story needs another conversation, not another pass.

Around the session: process mistakes

No reference story

The team estimates without an anchor. "What's a 5?" gets answered differently every sprint, and points drift over time without anyone noticing.

Pick one already-shipped story and call it the team's baseline. Re-anchor every quarter or after major team changes. Without a reference story, your velocity metric is a random walk.

Estimating before refinement

The story is two lines long. Half the team is mentally estimating "the version where we do it right" and the other half is estimating "the smallest possible version that fits the description". Both are correct; neither is what you'll ship.

The fix isn't faster estimation — it's slower refinement. Acceptance criteria, owner area, an idea of the edges, then estimate. Estimating to find out how big something is, instead of after, is how the same story ends up sized 3 in week one and 13 in week three.

Estimating in absentia

The team estimates a story whose owner-area is "the other team" or "whoever's on call when this lands". Whoever's in the room votes confidently because the work isn't theirs to do.

Don't estimate work the people in the room won't own. If a story crosses team boundaries, get representatives from both teams in the session or split the story along the boundary. An estimate from people who won't own the work isn't really an estimate.

Sessions that drag past 45 minutes

Estimation quality falls off a cliff after about 45 minutes. The cards get smaller, then they get bigger, then everyone plays whatever the lead plays.

Time-box the session, not just the stories. Cut at 45. If there's more backlog to size, schedule a second session — better still, reach for a faster technique like bucket sizing for the long tail.

Estimating bugs at feature precision

"Investigate the data corruption issue" gets a 5, the same as "Add a checkbox to the export dialog." One has a known scope; the other's whole nature is that you don't know what's in there.

Bugs and exploratory work usually deserve a different track — a time-boxed investigation (a day or two), then a follow-up story to actually fix what you find. Forcing them onto the feature deck pretends you have information you don't.

In the org: management mistakes

Velocity as a productivity metric

A manager somewhere starts comparing velocity across teams, or asking why this sprint hit 28 points and last sprint hit 32. Within two sprints, every estimate goes up by 30%.

Story points are a planning tool for the team that owns the work. The moment they're used to evaluate the team, the team starts gaming them — correctly, because they're being measured on them. There is no fix from inside the estimation session; this one has to be solved upstream.

Story-point inflation

Points drift up sprint over sprint without the work actually getting harder. Usually a sign of one of three things: velocity is being measured externally (see above), the reference story has slipped, or the team has stopped re-anchoring.

Audit by re-estimating five already-shipped stories from a year ago and seeing where they land now. If they're consistently bigger, your scale has moved.

The points-to-hours conversion table

Someone — usually well-intentioned — writes down "1 point = 4 hours" and shares it on the wiki. Within a sprint, every estimation conversation is a thinly-veiled hour conversation, and the relative-effort property is gone.

Burn the conversion table. If a stakeholder needs a date, project from the team's actual velocity (points per sprint × number of sprints), not from a fictional points-to-hours rate.

What good looks like

A team that does Planning Poker well isn't avoiding all of these — it's noticing them fast. The ritual is robust enough to recover from any of them in a single session, as long as someone in the room is paying attention.

New here? Start with what Planning Poker is and how to run a session. Or just open a session and try it on one easy story before the next one bites.