Agile Spikes: Time-Boxed Research to Reduce Uncertainty
A spike is a time-boxed investigation to answer a question or reduce uncertainty. It's a story whose deliverable is knowledge, not shippable code. Spikes are used to de-risk complex stories or evaluate technical options.
The mental model
A spike is a research mission to de-risk a future task. It's a special type of user story where the goal is not to deliver value to a customer, but to deliver knowledge to the team. You are explicitly setting aside time to learn, explore, or experiment, so that a future, more complex story can be estimated and executed with confidence. The output is an answer, not a feature.
How it works
A spike is created just like a user story. It's written down, discussed, and estimated in story points to represent the effort required for the investigation. It is then prioritized and placed in a sprint backlog. The team time-boxes the effort. At the end of the spike, the team presents its findings. The deliverable could be a recommendation, a diagram, a better estimate for a related story, or a simple proof-of-concept. Crucially, any code written during a spike is considered throwaway.
When to use it
Spikes are used to manage uncertainty. Three common scenarios are: first, when a user story is too big or complex to estimate accurately (a 'research spike' helps break it down); second, when the team needs to make a technical decision, like choosing between two libraries (a 'technical spike'); third, when exploring how to integrate with a new third-party API or unfamiliar legacy system.
When not to use it
Do not use spikes as a substitute for proper backlog refinement or to delay making decisions. If the question can be answered with a 15-minute discussion, it doesn't need a spike. Spikes are for genuine unknowns that require focused effort to resolve, not a parallel R&D track disconnected from delivering product features.
One canonical example
A team needs to add credit card payments. The story is too large and full of unknowns to estimate. The team creates a spike: 'Investigate Stripe vs. Braintree APIs' and estimates it at 3 points. During the sprint, two developers research both APIs, build tiny proof-of-concepts, and document the pros and cons. At the end, they recommend Stripe and can now provide a much more accurate estimate for the original user story. The throwaway code is deleted.
Interview question
What is the primary outcome expected from completing an Agile Spike?
- a.A fully implemented and tested feature ready for deployment to users.
- b.A detailed technical design document for the entire system architecture.
- c.A prototype or proof-of-concept that will be integrated into the main codebase.
- d.Actionable knowledge or a decision that reduces uncertainty for a future task.Correct
Why? this is the answer
The card states that a spike's deliverable is knowledge, not shippable code, and its purpose is to reduce uncertainty. While a spike can produce a proof-of-concept (option C), any code written during it is considered throwaway and not intended for integration into the main codebase.
Just read this? Test yourself on what you have been reading.
Read the original → mountaingoatsoftware.com
- #agile
- #scrum
- #estimation
- #risk management
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on agile — each one lists the topics its interview covers.
See open roles