Spike
A spike is a timeboxed research story — the team commits to spending a fixed amount of effort (1 day, 3 days, a sprint) exploring a question, with a defined deliverable (a recommendation, a prototype, a decision). Spikes exist because some stories can't be estimated until the unknowns are resolved; spiking first prevents the unknowns from blowing up a real sprint.
The deliverable of a spike isn't shippable code — it's a decision. Common spike outputs: an ADR with the chosen approach, a small proof-of-concept that gets discarded, a comparison matrix of alternatives, or a yes/no go-ahead on a feasibility question. The discipline is the time-box: a spike that runs over is a signal the team is doing implementation under spike's cover, which compounds risk.
Long-form posts that explore spike in depth — when to use it, common failure modes, how AI helps.
Related terms
- Story splitting
Story splitting is the practice of breaking a large user story into smaller stories that each independently deliver value.
- ADR
An Architecture Decision Record is a short document that captures a single architecture choice — what was decided, why, what alternatives were rejected, and what consequences the team accepts.
- Story points
A story-point estimate is a unit-less measure of relative effort assigned to a user story.