Spike
Last Updated: August 2026
A Spike is a small experiment that aims to reduce the risk of a nasty technical problem. It’s another idea borrowed from the Extreme Programming world. The goal of a Spike is to learn. A good spike gives the team enough information to make a decision about the real work.
They are:
- Short and Timeboxed usually 1-2 days work for one pair
- Experimental solutions that touch all relevant layers
- Always comprised of throwaway code
- Rare - only used as a last resort
It’s written fast, without worrying about code quality.
What they’re not:
- Estimated - they’re job is to reduce uncertainty, by definition exploratory work can’t be estimated.
- Don’t adhere to Definition of Done, this is a throwaway code
An example, in the personal expense management app I’m building, I was unsure which provider would be the most reliable receipt scanning system: Tesseract, Mistral, or other. I wrote a test harness to process a hundred receipts with each of them and then compared the results. None of that code was ever used in the production system.
Agile Pain Relief Blog Entries
Resource Links
- Why We Should Stop Using Spikes - Mike Bowler
- Agile Spikes Deliver Knowledge So Teams Can Deliver Products - Mike Cohn
- Create a Spike Solution - Extreme Programming Rules
- Spikes, They’re Sharp - Lagerweij Consulting and Coaching