What is a spike?
By Thimira Dulakshitha Kularatne · Updated
A spike is a short, time-boxed piece of research that answers a question the team needs answered before it can estimate or build something. When the cards in a planning poker round come back as ?, or spread from 2 to 21, a spike is often the right next step.
Two kinds of spike
- Technical spikes answer “can we, and how?”: whether a library fits, how an API behaves, how fast a query can get, or which of two approaches is simpler.
- Functional spikes answer “what exactly should it do?”: exploring the user flow, edge cases or business rules, often with a quick prototype or a conversation with users.
When to use one
- The team can’t estimate a story because a key fact is unknown.
- Estimates are spread widely, and the discussion keeps coming back to the same open question.
- You’re choosing between approaches with very different costs.
- A bug’s cause is unknown. See how to estimate bugs.
How to write a good spike
A useful spike has three parts:
- The question. One specific thing you need to know.
- The time-box. How long you’ll spend before stopping and reporting back.
- The output. What the team gets at the end: a decision, a short write-up, a prototype, or an estimate for the real story.
Example
Spike: Can we send receipts through our existing email provider, or do we need a new one?
Time-box: 1 day.
Output: A recommendation with any limits we found, and the “Email receipts” story broken down and ready to estimate.
Common mistakes
- No clear question. “Look into payments” never finishes. “Can we refund partial orders through our payment provider’s API?” does.
- No time-box. Without a limit, research expands to fill the sprint. Agree the time-box up front and stop when it runs out, even without a full answer.
- Building the feature inside the spike. A spike’s output is knowledge: a decision, a short write-up, a throwaway prototype. Production code belongs in a story estimated afterwards.
- Spiking everything. If most stories need a spike first, the backlog probably needs better refinement, or the team needs more time with the product owner.
After the spike
Share what you learned with the whole team, then estimate the real story with planning poker. If the spike did its job, the cards should land much closer together this time.
Questions
Where does the term “spike” come from?
It comes from Extreme Programming (XP): a quick, narrow piece of work that drives through a problem end to end, like a spike through a board, to learn whether an approach will work.
Should spikes get story points?
Teams differ. Some give spikes points so the sprint plan reflects the effort; others leave them unpointed and rely on the time-box. Either way, the time-box matters more than the number.
How long should a spike be?
As short as will answer the question: often a few hours to two days. If it needs more than a few days, the question is probably too broad.
Spot the stories that need a spike
In Benchmark, a wide spread after the reveal is flagged automatically, and private notes show why people picked their card. Both are good hints that a story needs research before it gets a number.