Learning Objectives
By the end of this lesson you will be able to:
- Name the four root causes of Planning Poker dysfunction
- Explain anchoring bias and how it contaminates estimates
- Identify the HiPPO effect and describe techniques to neutralize it
- Apply three concrete modifications to make Planning Poker produce honest estimates
The Theory vs the Reality
Planning Poker was designed around a core insight: if everyone reveals their estimate simultaneously, you get independent assessments. The high card and low card then explain their reasoning, and the group converges on an honest consensus.
In theory. In practice, most Planning Poker sessions have at least one of these four failure modes.
Failure Mode 1: Anchoring Bias
Someone says "I'd say this is probably an 8..." before the cards are flipped. Everyone adjusts their mental estimate toward that number. The simultaneous reveal is now theater.
Anchoring happens constantly in estimation:
- A senior developer mentions a "similar story that took us forever"
- The Product Owner says "I was thinking this was just a quick fix"
- Someone references a past estimate for a similar ticket
The fix: Enforce strict silence before reveal. Use physical cards or a Fibonacci poker app that hides individual selections until everyone has committed. Train the team to notice when anchoring is happening and name it explicitly: "That's an anchor — let's ignore it and estimate independently."
Failure Mode 2: Social Pressure (The HiPPO Effect)
HiPPO = Highest Paid Person's Opinion. When the tech lead, the architect, or the Engineering Manager expresses a view before everyone estimates, most people shift toward that number rather than risk disagreeing with authority.
This isn't just about seniority. It also happens with:
- The most vocal person in the room (not necessarily the most senior)
- The person who was blamed last time a story was under-estimated
- Anyone with visible frustration at the current number
The fix:
- Have the highest-status person estimate last during the reveal discussion (they've already shown their card, but hold their explanation).
- Explicitly normalize outliers: "We have a 2 and a 13 — these are both valuable. Let's hear the 2 first."
- Make it safe to be the outlier. Thank people for the divergent view.
Failure Mode 3: Undefined Acceptance Criteria
You can't estimate accurately what you haven't understood. When the story is vague — "Add user profile page" — every person in the room has a different picture in their head. The Developer imagines a simple form. The QA imagines edge cases for photo upload, responsive layout, and 20 character limit validation. The BA imagines a whole settings workflow.
This isn't an estimation problem. It's a refinement problem masquerading as an estimation problem.
The fix: Don't estimate stories that don't have written acceptance criteria. If a story arrives at Planning Poker without clear "Given/When/Then" or bullet-point acceptance criteria, mark it "Needs Refinement" and move on. Estimating unclear stories wastes everyone's time and produces garbage numbers.
Pro Tip: A 30-second check before Planning Poker: "Can everyone read these acceptance criteria and picture what Done looks like?" If the answer is no, don't estimate.
Failure Mode 4: The Fibonacci Debate (Is This a 5 or an 8?)
The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) is designed to encode the reality that larger stories have higher uncertainty. But teams often get stuck in extended debates between adjacent numbers — "is this 5 or 8?" for 20 minutes.
This misses the point. The difference between 5 and 8 is smaller than the estimation error inherent in any story over 3 points. These debates are rarely about the story — they're about different mental models of what the story contains.
The fix: When you have a 5/8 split, that's a signal that the story has hidden complexity or divergent understanding — not that one person is right and the other is wrong. Run a "split the 5/8" exercise: each person lists what they think the story includes. You'll usually find one person included X and the other didn't.
Summary
Planning Poker fails for predictable, fixable reasons: anchoring, social pressure, undefined requirements, and misdirected debates. Each has a concrete countermeasure. The team that addresses these systematically will produce estimates that are both more honest and more consistent — and will spend less time in Planning sessions doing it.