You’ve seen it before. The facilitator says “reveal,” everyone flips their cards, and it’s a wall of 5s. Sometimes 8s. Occasionally a lone dissenting 3 that gets quickly outvoted. The team nods, moves on, and you burn your sprint because the task was actually a 13.
This isn’t incompetence. It’s basic human psychology operating exactly as intended — just in the wrong context.
The anchoring effect in estimation
The anchoring effect is one of the most robust findings in behavioral economics. When people make numerical judgments under uncertainty, the first number they see or hear disproportionately influences their final answer.
In planning poker, this plays out in a specific way. Even though everyone writes their number “secretly,” there are almost always implicit anchors:
- The previous ticket: if your last story was a 5, the current one gets pulled toward 5.
- Who speaks first: whoever introduces the ticket often embeds an implicit size (“this should be quick” vs. “this touches a lot of systems”).
- Status in the room: junior developers unconsciously adjust toward what they think the senior engineers will pick.
The act of simultaneously revealing cards is specifically designed to prevent anchoring — but it only solves half the problem. The other half is that people discuss after the reveal, and discussion under social pressure produces consensus, not accuracy.
Groupthink isn’t a bug, it’s a feature (in the wrong place)
Teams that work well together tend to develop strong cohesion norms. These are useful: shared mental models speed up delivery, reduce conflict, and create psychological safety. But the same mechanism that makes your team cohesive makes them bad at estimation.
When a dissenting voice raises a 13 in a room full of 5s, the social cost of defending that position is real. The dissenter either explains themselves convincingly or quietly revises downward. Most people revise — not because they changed their technical assessment, but because being the outlier is uncomfortable.
The result: your estimates reflect your team’s social dynamics more than the actual complexity of the work.
What’s actually hard to estimate
There’s a second problem layered on top of the psychological one: story points measure the wrong thing.
Traditional planning poker produces a single number that supposedly represents “complexity” or “effort.” But a ticket can be small-effort, high-risk. Or low-complexity but uncertain in requirements. A 5-point story with a 40% chance of blowing up is fundamentally different from a 5-point story you’ve done ten times before — and switching to hours doesn’t fix this either.
When you collapse effort, risk, complexity, and uncertainty into one number, you lose the information that makes a vote meaningful. When people don’t know exactly what they’re estimating, they default to what feels safe — which is whatever the room seems to be converging on.
The structural fix
The same-number problem isn’t really about anchoring or groupthink in isolation. It’s what happens when you ask people to compress four different assessments into one card, then reveal them simultaneously and hope the process surfaces the disagreements that matter.
When a team votes on each dimension separately — effort first, then risk, complexity, uncertainty — the reveal changes character. Disagreements become specific: “I put Uncertainty as high because nobody on our team has touched this part of the codebase” is something the room can address. “I think it’s a 13” is something you can only negotiate.
The wall of 5s disappears not because people suddenly become braver about dissenting, but because the questions are specific enough that there’s no safe default. You either know what the risk is or you don’t. The honest answer surfaces whether you want it to or not.
If you want to try this with your team — Estimate Well runs structured multi-dimensional estimation sessions where the team votes separately on effort, risk, complexity, and uncertainty. Free, no account needed. Share a link and you’re in.