In 30 seconds
- A spike buys knowledge, not product.
- Timeboxed, often a day or two, with a clear question to answer.
- Ends with a decision or a better estimate.
What it is
The term comes from Extreme Programming. When a team can't estimate a story because of an unknown, such as an untested library, they run a spike: a quick, focused experiment to learn enough to move forward.
Two kinds
- Technical spike: will this approach or tool work?
- Functional spike: how should this behave for users?
Writing a good spike
- A clear question, such as "Can the payment API handle refunds?"
- A strict timebox
- A defined output: a decision, a prototype, or an estimate
Spike code is usually thrown away; the knowledge is what's kept.
Myth vs reality
Myth · Spikes are open-ended research.
Reality · They're strictly timeboxed.
Myth · Spike code goes to production.
Reality · It's usually throwaway; production code is rebuilt properly.
Myth · Spikes don't need estimates.
Reality · They get a timebox instead of a size.
The AI angle
AI makes spikes faster: a working prototype in hours instead of days. Keep the timebox and the throwaway rule; quick AI-built prototypes are especially tempting to ship without proper rework.
FAQ
How long should a spike be?
Usually a day or two, rarely more than a few days.
Do spikes count toward velocity?
Teams differ; many don't point them to keep velocity about delivered value.
When should we avoid spikes?
When a quick conversation or search would answer the question.