What is a spike?
A spike is a timeboxed investigation used to reduce uncertainty before the team can confidently estimate or commit to a piece of work. The output is knowledge — a recommendation, a proof-of-concept, a risk assessment — not shippable production code.
The name comes from a climbing spike: a short, focused effort hammered in to make the next move safer.
When to raise a spike
- Nobody on the team has touched this technology, library, or vendor API before.
- The team can't agree on an estimate because there are too many unknowns.
- A story would otherwise be committed at "T-shirt: XL" — too big to plan honestly.
- There's a risky third-party integration that might block the work entirely.
How spikes work
- Strict timebox — typically half a day to two days. When time runs out, the spike ends, regardless of progress.
- Concrete deliverable — a written recommendation, a small PoC branch, or a decision document.
- Estimable as a story point cost — count it against velocity like any other work.
- Drives a follow-up — the next sprint either picks up the now-estimable real story, or pivots away.
Spike vs story
A regular user story ships value to a user. A spike ships knowledge to the team so the next story can be safely committed. If you can't tell which one you're writing, it's probably a spike.
Common mistakes
- Open-ended spikes — "investigate Stripe" with no timebox always becomes a 2-week diversion.
- Shipping the spike — proof-of-concept code rarely meets the Definition of Done; rebuild, don't merge.
- Spike-everything — if every story needs a spike, the backlog isn't refined enough.