Planning poker mistakes and anti-patterns

Most failed planning poker sessions trace back to a short list of causes: bad refinement, anchored discussion, treating points as hours, and velocity used as a weapon. The ritual is robust enough to survive any of them in a single session — provided someone in the room notices. Here’s what to watch for, grouped by where it goes wrong.

In the room: voting and reveal mistakes

Estimating in hours

The team starts converging on hour-equivalents: 3 is half a day, 5 is a day, 8 is a couple. Once that mapping appears, you’re doing time-based estimation with a Fibonacci coat of paint, and the relative-effort property that story points exist to give you is gone. Re-anchor on the reference story and ban hour-talk for a round. If the team can’t have the conversation without translating to time, the problem is usually upstream — a stakeholder who only believes in dates.

Just averaging the cards

Someone plays a 3, someone plays a 13, the facilitator splits it at 8 and moves on. The whole point of the simultaneous reveal was to surface that disagreement; the average buries it. On a one-step spread (3s and 5s) take the higher number — that’s not averaging, it’s defaulting to the more cautious read. On a spread of two steps or more, you have a conversation, not an arithmetic problem.

The senior person’s number wins

Hidden cards stop the lead engineer from anchoring the vote — but not 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 get to anchor the discussion early keep their context instead of folding to seniority.

Re-voting until everyone gives up

By the third or fourth re-vote, the spread narrows because people are tired, not because they agree. The estimate that falls out is socially negotiated, not shared. Two votes per story is the right ceiling. Heading for a third? The story isn’t ready — split it, send it back to refinement, or punt. (The four-phase loop has the full sequence.)

Ignoring the ? card

Someone plays a ? and the room treats it as a non-vote — “anyone with a real number?” — instead of a stop sign. A ? is real information: someone can’t responsibly size this, which usually means the story is missing context, or 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 with no anchor, so “what’s a 5?” gets answered differently every sprint and points drift without anyone noticing. Pick one already-shipped story as the baseline and re-anchor every quarter, or after major team changes. Without a reference story, your velocity is a random walk.

Estimating before refinement

The story is two lines long. Half the team is estimating “the version where we do it properly” and the other half “the smallest thing that matches the description.” Both are right; neither is what you’ll ship. The fix isn’t faster estimation, it’s slower refinement — acceptance criteria, owner area, a sense of the edges, then estimate. Estimating to find out how big something is, rather than after, is how the same story gets sized 3 in week one and 13 in week three.

Estimating in absentia

The team sizes a story whose owner area is “the other team,” or “whoever’s on call when it 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 both teams represented or split it along the boundary. An estimate from people who won’t do 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 bigger, then everyone just plays what the lead plays. Time-box the session, not only the stories, and cut at 45. If there’s more to size, schedule a second session, or 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 of a day or two, then a follow-up story to 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 starts comparing velocity across teams, or asking why this sprint hit 28 points when the last hit 32. Within two sprints, every estimate is 30% bigger.

Story-point inflation

Points drift up sprint over sprint without the work getting any harder. Usually one of three things: velocity is being measured externally (above), the reference story has slipped, or the team has stopped re-anchoring. Audit it by re-estimating five stories you shipped a year ago and seeing where they land now. If they’re consistently bigger, your scale has moved. (More in velocity.)

The points-to-hours conversion table

Someone well-meaning writes “1 point = 4 hours” on the wiki. Within a sprint, every estimation conversation is a thinly veiled hour conversation, and the relative-effort property is gone again. Retire the conversion table. If a stakeholder needs a date, project it from the team’s actual velocity — points per sprint times the number of sprints — not from a fictional points-to-hours rate.

What good looks like

A team that runs planning poker well isn’t avoiding every one of these — it’s noticing them fast. The mechanic is robust enough to recover from any single mistake in one session, as long as someone is paying attention to the spread, the anchor, and the clock.

New to the technique? 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.

Frequently asked questions

What are the most common planning poker mistakes?

Averaging the cards instead of discussing the spread, estimating in hours, letting the senior person’s number win the discussion, re-voting until people give up, estimating before refinement, and treating velocity as a productivity metric. Most failed sessions trace back to one of those.

Why is averaging story points a mistake?

The simultaneous reveal exists to surface disagreement; averaging buries it. A 3 and a 13 do not mean 8 — they mean two people are estimating different stories. Take the higher number on a one-step spread, and have a conversation on anything wider.

Is it wrong to convert story points to hours?

Yes. The moment 1 point = 4 hours goes on the wiki, every estimate becomes a duration argument and the relative-effort property is gone. If a stakeholder needs a date, project it from the team’s velocity, not from a per-story conversion.

How long should a planning poker session be?

Cap it around 45 minutes. Estimation quality falls off a cliff after that — cards drift and people start playing whatever the lead plays. If there is more backlog, schedule a second session or switch to a faster technique like bucket sizing.

Should you re-vote in planning poker?

Once, maybe twice. By the third re-vote the spread narrows because people are tired, not because they agree. If you are heading for a third round, the story is not ready — split it or send it back to refinement.