Agile Spikes: Time-Boxed Research to Reduce Uncertainty

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.