The Estimation Paradox
You're in planning poker. The Product Owner presents a story. You read it. Re-read it. And realize: you have absolutely no idea how to estimate this.
Good. That uncertainty is valuable data. The question isn't whether to estimate—it's how to handle what you don't know. This guide shows you exactly how.
The Four Types of Unknowns
Known Knowns
95%Things you know and understand completely
EXAMPLE
Updating a button color. You've done it 100 times.
Known Unknowns
60%You know what you don't know. Questions are specific.
EXAMPLE
API integration - you know the vendor, but haven't read their docs yet.
Unknown Unknowns
20%You don't even know what questions to ask yet.
EXAMPLE
Building a feature in a technology you've never touched.
Unknowable Unknowns
0%External dependencies completely outside your control.
EXAMPLE
Waiting for vendor support to answer a critical question.
The Cone of Uncertainty
Estimates get more accurate as you progress. Early-stage uncertainty is normal—embrace it.
Initial Concept
Requirements
Design Complete
Development
Testing
Key Insight: A 5-point estimate at the initial concept phase could realistically be anywhere from 1 to 20 points. Don't fight this—accept it and use spikes to narrow the cone.
When to Use "?" or Coffee Cup Cards
You've never worked with this technology
Not even sure where to start. Need research time.
You need information from an external team
Can't estimate until they respond.
The requirements are vague or contradictory
Need clarification before sizing.
It's just complex, but you know the domain
Use a high number (13, 21) instead. Complexity ≠ uncertainty.
You're worried about edge cases
Factor that into your estimate. Don't hide behind "?"
It depends on another unfinished story
Dependency creates genuine uncertainty.
Using Spikes for Research
A spike is a time-boxed research task designed to reduce uncertainty. It's not about building the feature—it's about gathering enough information to estimate it.
Technical Spike
Can we integrate with this third-party API?
Proof-of-concept showing auth flow + one working endpoint
Yes (8 pts), No - use alternative (13 pts), or Blocked
Architectural Spike
How should we structure our microservices?
Diagram showing service boundaries + data flow
Team alignment on approach, ready to estimate features
Research Spike
Which charting library should we use?
Comparison matrix with recommendation
Decision made, confidence to estimate implementation
✓ Good Spike
- Time-boxed (2-8 hours max)
- Specific question to answer
- Clear deliverable (proof-of-concept, diagram, decision)
- Reduces uncertainty enough to estimate
⚠️ Bad Spike
- No time limit ("investigate until we figure it out")
- Vague goal ("learn about microservices")
- Actually building the feature
- No deliverable—just "more knowledge"
Risk vs Uncertainty: Know the Difference
Uncertainty
You don't have enough information. Solvable through research, spikes, or asking questions.
EXAMPLES
- • Which API endpoint to use?
- • Does the library support our use case?
- • What's the performance impact?
Risk
You know what could go wrong. Can't eliminate it, but you can plan for it or mitigate it.
EXAMPLES
- • Third-party API might be slow
- • Database migration could fail
- • User might reject the design
How to handle each: Uncertainty needs investigation. Risk needs padding in your estimate. If you're uncertain about a risk, do a spike first.
Making Decisions with Incomplete Information
Time-box the Unknown
Set a fixed time limit for research. Make a decision when time expires.
Spend 4 hours investigating. If still unclear, assume worst case.
Known unknowns with specific questions
Parallel Paths
Explore multiple solutions simultaneously. Pick the winner.
Two devs try different approaches for 2 hours. Use whichever works.
Multiple viable options, unclear which is better
Pessimistic Estimation
Assume the worst. Estimate for the hardest scenario.
If it might be 5 or might be 21, estimate 21.
Can't reduce uncertainty but need to commit
Break It Down
Split into a known piece + unknown piece.
UI (known: 5pts) + API integration (unknown: spike first)
Story has both clear and unclear components
Walking Skeleton
Build the simplest end-to-end version first.
Get one API call working, then estimate the full feature.
Unknown unknowns in how pieces connect
The Power of Time-Boxing
Unknowns can spiral into endless research. Time-boxing forces a decision with the information you have.
Quick library comparison
Technical spike or proof-of-concept
Architectural decision or major research
Time-box Rule: Set a timer. When it expires, make the best decision you can with the information you have. Perfect information rarely exists.
Better to make a good-enough decision quickly than a perfect decision too late.
✓ Key Takeaways
- 1Distinguish between known unknowns (solvable with research) and unknown unknowns (need exploration)
- 2Use "?" cards only for genuine uncertainty, not just complexity
- 3Time-box all spikes—2 to 8 hours max for most unknowns
- 4The cone of uncertainty narrows as work progresses—early variance is expected
- 5When in doubt, estimate pessimistically or split the story into known + unknown pieces
Practice Estimating with Unknowns
Use planning poker with your team. When uncertainty strikes, you'll know exactly what to do.
Start Free Planning Session