poc-spike

POC / Spike

Purpose

Validate risky technical assumptions before committing to full implementation. Produce throwaway, minimal code that answers specific questions — then document the findings so the team can make informed go/no-go decisions.

A spike is NOT an implementation. It is an experiment with a findings report.

When to Use

• Gate 2 (Design) identified high-risk or uncertain technical items
• User asks to "spike", "prototype", "prove out", or "POC" something
• A technology/integration choice needs hands-on validation before commitment
• Performance or scalability assumptions need benchmarking
• User asks "will this even work?" or "can we actually do X?"

When NOT to Use

• Requirements are unclear (use requirement-study first)
• No design exists yet (use implementation-sketch first)
• User wants production-quality code (that's Gate 4: Implementation)
• The risk is a business/market risk, not a technical one (use idea-to-mvp instead)

Inputs

Required:

• Risk items to investigate — specific technical questions to answer (ideally from Gate 2 risk register)

Optional:

• Implementation sketch — the design context for the risks
• Constraints — time box, technology restrictions, environment limits
• Success criteria — what constitutes a "validated" risk item

Process

Step 1: Define the Spike Scope

For each risk item, write a clear hypothesis and exit condition:

**Spike Item:** [SPIKE-NNN]
**Risk Source:** [REQ-NNN or risk register item]
**Hypothesis:** "We believe [technology/approach] can [achieve X] within [constraint Y]"
**Validation Method:** [What we'll build/test to prove or disprove]
**Exit Condition:** [Specific, measurable condition that answers the question]
**Time Box:** [Maximum time to spend — stop even if inconclusive]

Present the spike scope to the user:

"Here are the spike items I plan to investigate: [list]. Each has a time box of [N]. Does this scope look right?"

Do NOT proceed until the user confirms the scope.