The Spike is a timeboxed investigation created to answer a technical question — research, dressed in a JIRA ticket’s clothing so it can appear on the sprint board alongside real work and be pointed, tracked, and closed like a story, even though its deliverable is not software but a sentence that usually reads: “Yes, it’s feasible. We think.”
The term comes from Extreme Programming, where a “spike” was a quick, focused experiment driven through the codebase like a steel spike through wood — penetrating the unknown to see what’s on the other side. The metaphor is violent and effective. The practice has become neither.
In modern usage, a spike is what happens when a team encounters a question they cannot answer without research, and the research must be legitimized by appearing on the sprint board, because work that is not on the board does not exist, and research that is not on the board is “not planned work,” which is the agile equivalent of being absent without leave.
The Anatomy
A spike has:
- A question — “Can we use Elasticsearch for this?” “What’s the performance impact of switching to GraphQL?” “Is it possible to integrate with their API?”
- A timebox — Typically one to two days. The timebox exists to prevent the spike from becoming a project. The timebox is frequently exceeded, because the answer to most technical questions is “it depends,” and “it depends” takes longer than two days to articulate.
- A deliverable — A document, a Confluence page, a Slack message, or a verbal report in standup. The deliverable is not code. The deliverable is knowledge, which is harder to point, harder to demo, and harder to put on a burndown chart.
- Zero story points — Spikes are not estimated, because estimating research is like estimating how long it takes to have an idea. Some teams estimate them anyway, because the velocity chart demands points and the velocity chart is hungry.
The Spike Chain
The most dangerous spike pattern is the spike chain — a spike whose conclusion is “we need another spike.”
Spike 1: “Can we use Elasticsearch?” → “Maybe, but we need to test performance.”
Spike 2: “How does Elasticsearch perform with our data?” → “Acceptable, but we need to evaluate the hosting cost.”
Spike 3: “What does Elasticsearch hosting cost?” → “More than expected. We need to spike an alternative.”
Spike 4: “Can we use Meilisearch instead?” → “Maybe, but we need to test performance.”
The spike chain is research that has forgotten it was supposed to inform a decision. Each spike answers its question honestly and poses a new one. The chain continues until someone — usually a developer, rarely the researcher — builds the feature using the boring technology that was available before the first spike was filed.
The Lifelog Alternative
In the lifelog, spikes are replaced by doing the thing.
When the question was whether SQLite could handle full-text search, the answer was not a spike. The answer was building it.
“By the time the Squirrel had opened Jira — sorry, Linear — to create a sprint board, the parser was handling frontmatter that even strict YAML couldn’t parse.”
— The Homecoming, or The Three Days a Palace Was Built From Markdown and SQLite
The Lizard’s spike is building the feature. If it works, the spike is complete and the feature is shipped — simultaneously. If it doesn’t work, the spike is complete and the feature is deleted. Either way, the deliverable is not a Confluence page. The deliverable is code that either runs or doesn’t.
This approach does not scale. It does not produce documentation. It does not appear on the sprint board. It does, however, produce software — which is the thing the spike was supposed to enable but frequently displaces.
The Fundamental Question
The spike answers: “Can we do this?”
The Lizard answers: “Let’s find out.”
The difference is not philosophical. It is temporal. The spike answers the question before the work. The Lizard answers the question by doing the work. The spike produces knowledge. The Lizard produces software. Sometimes the software is wrong and gets deleted. But deleted software answered the question faster than a two-day spike followed by a Confluence page followed by a sprint planning meeting followed by the actual implementation.
The spike’s greatest irony: the best way to determine if something is feasible is to build it. And if you’ve built it, you don’t need the spike.
