Estimating with Uncertainty: Techniques for the Unknown

Not every backlog item is well understood. Some have technical uncertainty, others have vague requirements, and others are simply new to the team. How do you estimate the unknown?

Levels of Uncertainty

Level 1: Known Knowns

“We’ve done this 5 times. Estimate: 3 points.”

Certain. Based on direct experience.

Level 2: Known Unknowns

“We’ve never done social login, but we know what OAuth is.”

Estimate by analogy and add a buffer:

• “Local login was 3 points. Social login is similar but with provider complexity: 5 points.”

Level 3: Unknown Unknowns

“We need ML to detect fraud. We know nothing about this.”

Do not estimate. Create a spike.

Technique: Cone of Uncertainty

At the beginning of a project, uncertainty is enormous (±4x to ±0.25x). As the team learns, the cone narrows.

Uncertainty
  |
  |   ╱╲
  |  ╱  ╲
  | ╱    ╲
  |╱      ╲
  +━━━━━━━━━━━ Time
     Sprint →

Implication: Release estimates in Sprint 1 should be wide ranges. By Sprint 6, they become precise.

Technique: Three-Point Estimation

For each uncertain item, estimate three scenarios:

Scenario	Value	Weight
Optimistic (O)	3 points	1
Most Likely (M)	5 points	4
Pessimistic (P)	13 points	1

Estimate = (O + 4M + P) / 6 → (3 + 4×5 + 13) / 6 = 36/6 = 6 points

This captures the asymmetry of uncertainty.

Technique: Story Splitting by Risk

For highly uncertain items, split:

“Recommendation system” → 21 points (too uncertain)

Split into:

1. Spike: Evaluate recommendation libraries → 5 points (2 days)
2. MVP: Popularity-based recommendation → 8 points
3. Advanced: ML-based personalized recommendation → 13 points

The spike reduces uncertainty and subsequent estimates become more accurate.

Technique: Risk Poker

A Planning Poker variation where the team votes on risk instead of effort:

• 🟢 Low: we have experience, known technology
• 🟡 Medium: some familiarity, but with rough edges
• 🔴 High: new technology, unknown domain

🔴 items should have spikes before estimating. 🟡 items get a 30-50% buffer. 🟢 items are estimated normally.

When NOT to Estimate

• New technological paradigm — spike first
• Requirement too vague — PO needs to clarify
• Critical external dependency — resolve the dependency first
• Epic too large — decompose before estimating

Estimating Exploratory Projects

When the product is a discovery (e.g., “let’s explore whether AI solves this problem”):

1. Timebox the exploration — “3 sprints of investigation”
2. Define success criteria — “If accuracy > 90%, we continue. If not, we discard it.”
3. Estimate the exploration, not the result — “3 sprints × 25 points = 75 points of exploration”

Conclusion

Uncertainty is not an excuse to avoid estimates — it is a signal to estimate differently. Use techniques like three-point estimation, Risk Poker, and spikes to transform the unknown into the known, and then estimate with confidence.