HKSM
Risk-Based Spike
A short, time-boxed investigation that uses research and lightweight prototypes to explore and reduce project risks. Typically run for two to three days early in the effort—ideally before defining epics or creating the prioritized product backlog—it helps the team uncover unknowns and clarify uncertainties that could affect delivery.
Key Points
- Time-boxed effort (about 2–3 days) aimed at risk discovery and reduction.
- Relies on research and quick prototyping to test assumptions and explore unknowns.
- Best scheduled early, before developing epics or building the prioritized product backlog.
- Delivers findings, prototypes or notes, and decisions that feed the backlog and risk register.
Example
A team planning a new app must integrate a third-party payment gateway but is unsure about SDK stability and PCI implications. They run a 2-day risk-based spike to integrate the sandbox, test edge cases and latency, and review compliance requirements. The results reveal a throughput risk, leading to new performance stories, clearer acceptance criteria, and a mitigation plan.
PMP Example Question
Early in an agile project, the team faces high uncertainty about integrating a new cloud OCR service. What should the team do to manage this risk?
- Add extra schedule buffer and proceed with development.
- Run a time-boxed risk-based spike to research and prototype the integration before refining the backlog.
- Defer the integration to a later release to reduce near-term complexity.
- Request a vendor guarantee and document an assumption.
Correct Answer: B — Run a risk-based spike
Explanation: A risk-based spike directly investigates the uncertainty early, generating evidence and decisions that inform the backlog and risk responses.
