Most broken estimation isn't caused by bad math. It's caused by group dynamics that push a team toward a comfortable number instead of an honest one. These patterns are so common they're almost invisible — which is exactly why they're worth naming. Here are the four I see most, and what actually counters them.
1. Anchoring
Anchoring is the gravitational pull of the first number mentioned. Someone says "this feels like a 5" during the discussion, and now every estimate clusters around 5 — not because the team agrees, but because 5 is now the reference point in everyone's head. The estimates look like consensus. They're actually an echo.
The counter
Vote before you talk. The whole design of Planning Poker — private selection, simultaneous reveal — exists to kill anchoring. Enforce it strictly: no numbers spoken until every card is in.
2. The HiPPO effect
HiPPO stands for the Highest Paid Person's Opinion. When the manager, the architect, or the loudest senior estimates first — or reacts visibly to others' estimates — the room recalibrates toward them. Juniors who'd have said 8 quietly change to 3 because the lead looked confident about small. You lose exactly the diverse perspectives estimation is supposed to gather.
- Have the most senior person reveal last, or at least react last.
- When there's a spread, ask the most junior estimator to explain their reasoning first — before the room's centre of gravity forms.
- As the lead, model curiosity, not verdicts: "interesting, tell me what you're seeing" beats "nah, that's small."
3. 'Just average it'
The cards reveal 2, 3, 3, and 13. Someone says "let's just call it a 5 and move on." This is the most tempting anti-pattern because it feels efficient — and it throws away the single most valuable signal in the session. That 13 isn't noise to be averaged out. It's a person who knows something. Averaging silences them and bakes their unspoken risk straight into the sprint.
Why averaging is a trap
An estimate spread is information, not error. The gap between the low and high card is a map to hidden assumptions. Average it away and you've deleted the map while keeping the risk.
The counter is simple: never average a wide spread. Talk it out, let the outliers explain, then re-vote. If after two rounds the spread holds, the story isn't understood well enough to estimate — which is itself a decision (split it, spike it, or park it), and a far better outcome than a made-up middle number.
4. Estimates that harden into deadlines
This one happens after the session, often outside the team's control. An estimate of "8 points" gets translated by someone up the chain into "so, done by Thursday?" Once estimates are treated as commitments, teams learn the lesson quickly: pad everything, or refuse to estimate at all. Both destroy the tool.
- Keep the vocabulary separate: points are for relative sizing, forecasts come from velocity over time — never from a single estimate.
- Report ranges and confidence to stakeholders, not single dates derived from one sprint's guess.
- Protect the team's honesty: if estimates are used as a stick, you'll get defensive padding instead of useful signal.
5. Point inflation
This one creeps in over quarters, not sessions. A team gets praised when velocity goes up, so — without anyone deciding to cheat — sizes drift. The story that was a 3 last spring is a 5 now. Velocity climbs beautifully; throughput doesn't change at all. The chart says the team is improving. The release dates say otherwise, and eventually a stakeholder notices the gap.
The root cause is almost always velocity being used as a performance metric. Velocity is a planning input, and it only works while nobody is rewarded for it. The counters: keep old anchor stories visible so "what does a 3 look like" has a stable answer; re-calibrate against them every few months; and if velocity appears in a management dashboard next to team names, have that conversation — the metric is already being gamed, whether anyone admits it or not.
6. Estimating alone and splitting by layer
Two related shortcuts that both undermine the point of a shared estimate. The first: the tech lead sizes the whole backlog solo the night before planning "to save time". The numbers may even be decent — but the team never had the conversation, so the hidden assumptions never surfaced, and nobody feels ownership of the sizes they're now committed to. The second: splitting one story into a "frontend 3", a "backend 5" and a "QA 2". Now nobody owns the outcome, integration work belongs to no card, and three people wait on each other inside a single sprint.
- Estimate as the team that will do the work — the discussion is the deliverable, the number is a receipt.
- Size vertical slices (a thin end-to-end piece of behaviour), not horizontal layers.
- If solo pre-sizing is truly needed for a roadmap, label those numbers as drafts and re-estimate together before commitment.
How to spot these in the wild
Anti-patterns rarely announce themselves; they hide in small tells. Estimates that always match the first opinion voiced. Reveals where nobody is ever surprised. A velocity chart that only goes up while the roadmap slips. Retros where estimation is never mentioned because "it works fine". A useful habit is to spend five minutes in every second retro on a single question: "Which story surprised us most this sprint, and what did we miss when we sized it?" That one question, repeated, will surface every pattern on this list eventually.
A 30-second team self-check
Read these four statements to your team at the next retro and ask for a silent thumbs up or down on each: our estimates change depending on who speaks first; disagreement in a reveal usually gets discussed rather than averaged; a bigger estimate never has to be justified to a manager; our velocity chart looks the same to us as it does to leadership. Two or more thumbs down and you've found your next improvement topic — and unlike most process debates, this one comes with concrete counters you can apply in the very next session. Fixing a single anti-pattern typically shows up in estimate quality within two sprints.
The common thread
Every one of these anti-patterns is really about psychological safety and independence. Anchoring and HiPPO are failures of independence — people stop thinking for themselves. Averaging and deadline-creep are failures of safety — the team learns that honesty is punished, so it stops being honest. Good facilitation is mostly the discipline of protecting both.
The mechanics help. Private, simultaneous voting removes two of the four patterns almost for free. You can run a session with hidden voting in seconds, and if you want the deeper theory behind why the spread matters, the agile estimation guide goes further.