Someone voted 3. Someone else voted 13. Cards are on the table, everyone’s looking at each other, and the negotiation begins. Twenty minutes later you land on 8 and move on. Nobody is confident. The sprint will tell you who was right.
Here’s what that moment actually is: both votes were probably correct.
Two right answers to two different questions
The developer who voted 3 was thinking about effort. She’s done this kind of change before — it touches one service, the pattern is established, it’s maybe half a day of focused work.
The developer who voted 13 was thinking about risk. That service feeds three downstream systems, and the last time someone touched it without checking all three, it was a two-day incident.
Neither of them is wrong. They’re not even disagreeing about the same thing. But your estimation process asked them to express two separate assessments as a single number, so now you’re negotiating between answers to different questions — and whatever you land on loses information from both of them.
What a single number can’t carry
This is the structural problem with standard planning poker. A story point is supposed to capture how hard a ticket is. But “hard” conflates at least four distinct things:
Effort — how much work this actually requires. Hours of focused engineering.
Risk — what external factors could make this go wrong. Dependencies, shared infrastructure, proximity to sensitive systems.
Complexity — how hard the code is to understand and navigate safely. Technical complexity and domain complexity are both real and both different from effort.
Uncertainty — how much you don’t know yet. Unclear requirements, unfamiliar codebase, no clear definition of done.
These four dimensions don’t move together. A ticket can be low effort and high risk — one line in the payment service. High complexity and low uncertainty — a hard algorithm you’ve implemented before. High uncertainty and everything else low — a simple feature with requirements nobody’s pinned down yet.
When they all get compressed into one number, the only way to arrive at consensus is to negotiate. And negotiation under social pressure doesn’t converge on accuracy. It converges on whatever the room is willing to defend.
What the disagreement is actually telling you
The 3 and the 13 aren’t a communication problem. They’re signal.
If you asked both developers separately — “what’s the effort here?” and “what’s the risk here?” — you’d probably get near-identical answers. Low effort. High risk. They’d agree immediately. The disagreement only exists because you forced two compatible assessments into a format where they look like a contradiction.
That’s the moment that changes sprint planning. “Low effort, high risk” gives you something to act on: assign this to the person who knows the payment service, budget time for testing, flag it before the sprint. “8 story points” gives you a position on a scale that everyone knows is unreliable.
The spread in the vote was information. Standard planning poker formats that information as a dispute.
What changes when you separate the questions
When a team votes on effort, risk, complexity, and uncertainty as four separate questions before arriving at a final number, two things happen.
First, the disagreements get specific. “I put Risk as high because this touches the payment service and I know what it feeds into” is something the team can discuss, resolve, or flag. “I think it’s a 13” is something you can only negotiate.
Second, the agreements become visible. Teams are often surprised how often they actually agree on three of the four dimensions — the argument was only ever about one of them. The wall of 5s has a different cause, but the 3-versus-13 problem is almost always this: two people who agreed on everything except the one dimension that matters most for this ticket.
The final story point becomes an aggregation of four honest assessments rather than a social negotiation over one vague one. You still get a number for your sprint board. You also get the information behind it.
If you want to try this with your team — Estimate Well runs structured multi-dimensional estimation sessions. Free, no account needed. Share a link and you’re in.