Handling Estimation Uncertainty - Confidence Levels in Planning Poker
When estimating stories with significant unknowns, how do you handle uncertainty? Do you add points for risk? Use confidence levels? Our team debates between estimating optimistically (best case) vs pessimistically (worst case).
Use three-point estimation borrowed from PERT: optimistic, most likely, pessimistic. Vote on all three scenarios in planning poker, then use weighted average: (O + 4M + P) / 6.
Example: Database migration story. Optimistic 3pts (no issues), Most likely 5pts (normal complexity), Pessimistic 13pts (data corruption edge cases). Final estimate: (3 + 20 + 13) / 6 = 6 points. This captures uncertainty mathematically without inflating every estimate.
We use confidence tags: Green (90%+ confident in estimate), Yellow (50-90% confident), Red (<50% confident). Red stories automatically require a spike story first.
This forces honest conversation about unknowns. Better to spend 2 points on a spike than 13 points building the wrong solution. Product owner decides if spike is worth it or story gets deferred.
Estimate the known work only, add explicit spike stories for unknowns. Don't pad estimates with "uncertainty tax." If story has unknown API integration, create separate 3-point spike: "Research payment gateway API compatibility."
Keep estimates honest. Velocity naturally accounts for some variance. Padding every estimate means you lose the signal of what's actually complex vs what's uncertain.
Controversial take: Always estimate pessimistically. Under-promise, over-deliver builds stakeholder trust. Team velocity naturally accounts for optimism bias over time.
I'd rather finish sprint early and pull another story than scramble at sprint end explaining why we're at 60% complete. Predictability > throughput for business relationships.