name: assumption-grading description: Assess assumptions on certainty and risk to prioritize validation efforts. Use at project start or before phase transitions.

Assumption Grading

Overview

Systematically assess assumptions to identify which ones need validation and prioritize research efforts.

When to Use

• At project start to grade initial assumptions
• During Define phase when framing the problem
• Before phase transitions to assess remaining risks
• When deciding what to research next

How to Apply

1. List Assumptions

Identify what you're assuming to be true. Common sources:

• Beliefs about user behavior
• Market or business conditions
• Technical feasibility claims
• Resource availability
• Timeline estimates

2. Grade Each Assumption

Assess on two dimensions:

CERTAINTY — How confident are we this is true?

• High: Strong evidence, validated with users/data
• Medium: Some evidence, but not thoroughly validated
• Low: Gut feeling, no validation yet

RISK — What's the impact if we're wrong?

• High: Project fails, major wasted resources, wrong direction
• Medium: Significant rework needed, delays, budget impact
• Low: Minor adjustments, easy to correct

3. Prioritize Validation

Focus on assumptions that are:

1. Low certainty + High risk — VALIDATE IMMEDIATELY
2. Low certainty + Medium risk — Validate before major commitments
3. Medium certainty + High risk — Validate before proceeding
4. High certainty + Low risk — Can proceed with monitoring

4. Plan Validation

For each high-priority assumption, define:

• What would prove this true or false?
• What's the cheapest/fastest way to test it?
• Who can provide evidence?
• When do we need to know?

5. Update currentstate.json

Record each assumption with:

{
  "id": "a1",
  "description": "Users want automated reporting",
  "certainty": "low",
  "risk": "high",
  "validation_plan": "Interview 5 users about reporting needs and current workflows",
  "status": "open"
}

Example Assessment

Assumption: "Users will adopt mobile app over desktop"

• Certainty: Low (based on industry trends, not our users)
• Risk: High (entire platform strategy depends on this)
• Priority: VALIDATE IMMEDIATELY
• Validation Plan: Interview current users about device usage patterns and preferences

Assumption: "API can handle 1000 requests/second"

• Certainty: Medium (vendor specs, but not tested)
• Risk: High (performance is core requirement)
• Priority: Validate before prototyping
• Validation Plan: Load testing with production-like data

Assumption: "Users understand technical jargon"

• Certainty: Low (no evidence)
• Risk: Low (can adjust language easily)
• Priority: Test during iteration, easy to fix

Tips

• Be explicit about what you're assuming
• Don't confuse hope with certainty
• High certainty still means "could be wrong"
• Update grades as you learn
• Re-grade assumptions at phase transitions