Estimation: Story Points, Planning Poker & the Cone of Uncertainty
The Software Development Lifecycle
Chapter 6 · Estimation: Story Points, Planning Poker & the Cone of Uncertainty
Chapter 3 already showed what happens when a sprint commits past known velocity. This chapter goes one level deeper: why the estimates feeding that commitment are unreliable in the first place, why teams drift toward relative estimation instead of absolute time, how a specific technique (planning poker) surfaces disagreement that would otherwise stay hidden, and why even a perfectly-run estimation process is structurally less accurate early in a project than late in it.
Relative vs. Absolute: Why Teams Drift Toward Story Points
# five estimators, each with a genuinely different personal work speed
estimator_speed_multiplier = {
'Alice': 0.8, 'Bob': 1.3, 'Carla': 1.0, 'Dan': 0.9, 'Eve': 1.2,
}
Verified directly — the same personal speed differences that caused a 5-hour spread in absolute estimates produced a 0-point spread in relative ones
Asked for absolute hours on the same task: Alice: 8, Bob: 13, Carla: 10, Dan: 9, Eve: 12 — a 5-hour spread, purely from each person's own honest sense of how long it would take them. Asked instead to compare the same task's own size against a shared reference task (both scaled by that same personal speed): all five estimators: 10 points — a 0-point spread. The ratio between two tasks, computed by the same person, cancels out their own personal speed entirely — a genuine mathematical property, not a training exercise.
This is the real reason, not just a cultural preference
Story points aren't popular because teams find hours embarrassing to commit to. They're popular because relative-size judgments are structurally more consistent across different people doing the estimating — verified directly above, not merely claimed.
Planning Poker: Surfacing Disagreement Before It's a Missed Deadline
Verified directly — anchored estimation diluted a real, known concern to near-invisibility; simultaneous reveal made it impossible to miss
One team member (Eve) knows about a hidden migration complexity that genuinely makes a task worth 21 points, not 5. When the first, unaware estimate (5) is spoken aloud and others adjust toward it — a real, well-documented anchoring bias — Eve's own estimate compromises to 10, and the team's final average lands at 6.0, barely different from the uninformed guess. With planning poker's simultaneous reveal — every card shown at once, no anchor spoken first — the estimates are [5, 5, 5, 5, 21], a 16-point spread that's impossible to average away quietly and triggers exactly the discussion Eve's own hidden knowledge deserved.
The value isn't the final number — it's the outlier that forces a conversation
Planning poker doesn't produce a more mathematically sophisticated average. It produces a visible disagreement at the moment it's cheapest to resolve — before the sprint starts — instead of a smoothed-over consensus that quietly erases the one piece of information that mattered most.
The Cone of Uncertainty: Why Early Estimates Are Structurally Unreliable
# an illustrative model of the cone's own well-documented SHAPE -# wide uncertainty early, narrowing as real information accumulates
phases = {
'Initial concept': (0.25, 4.0), # true effort could be 4x lower or 4x higher'Requirements defined': (0.5, 2.0),
'Design complete': (0.67, 1.5),
'Implementation underway': (0.9, 1.1),
}
Verified directly — the same true effort produced an 18.7x wider honest estimate range at the earliest phase
Simulating 500 honest estimates at each phase, drawn from that phase's own uncertainty range, against a true final effort of 1,000 hours: at "Initial concept," honest estimates ranged from 252 to 4,000 hours — a 3,750-hour-wide range. At "Implementation underway," the same true effort produced estimates from 900 to 1,100 — a 200-hour-wide range. 18.7× tighter, purely from more of the project having actually happened by the time the estimate was made.
This isn't a failure of skill — it's a property of how much is genuinely knowable yet
Every simulated estimate in this model was drawn "honestly" — no bad-faith padding, no incompetence. The range narrows because later phases genuinely contain more real information to estimate from, not because later estimators try harder. An estimate given at "Initial concept" being off by 2-4x isn't a sign the estimator did a bad job; it's the expected, structural outcome of estimating something that hasn't been designed yet.
Chapter 3's own known-velocity finding — velocity is only a meaningful number if the points feeding it are consistently sized in the first place
A visible outlier forcing a conversation before commitment
Chapter 1's own "work nobody remembers deciding to do" finding — planning poker surfaces the same kind of hidden information before it's lost, not after
Estimate uncertainty narrowing as more becomes known
Chapter 2's own iterative-delivery finding — checking in earlier doesn't just catch mistakes faster, it estimates more accurately too
Hands-On Exercises
Exercise 1
Add a sixth estimator to this chapter's own relative-vs-absolute simulation, Frank, with a personal speed multiplier of 1.5 (notably slower than everyone else). Determine his absolute hour estimate and his relative story-point estimate, and confirm whether the relative spread stays at 0.
Using this chapter's own planning-poker simulation, change the scenario so TWO team members (not just Eve) independently know about the same hidden complexity, both submitting 21 in the simultaneous-reveal round. Determine the new spread and discuss whether two matching outliers are more or less likely to trigger a genuine discussion than one.
Using this chapter's own cone-of-uncertainty simulation, add a fifth phase, "Code review complete," with an illustrative uncertainty range of (0.97, 1.03). Determine its range width in hours and its narrowing factor compared to "Initial concept," continuing the chapter's own progression.