One of the concepts that came from XP is the Spike. Especially in teams new to agile, there can be confusion on what a Spike is, and how to deal with them.
The best definition of a Spike I’ve found is this one:
“Spike”; is an Extreme Programming term meaning “experiment”;. We use the word because we think of a spike as a quick, almost brute-force experiment aimed at learning just one thing. Think of driving a big nail through a board.
— Extreme Programming Adventures in C# - Ron Jeffries
Let’s break this down.
Experiment
A Spike is an “… experiment aimed at learning just one thing”;. That means that a Spike always starts with a question to be answered. An Hypothesis. At the end of the Spike there is an answer to that question. The hypothesis has been proved, or disproved. And that proof takes the form of a piece of software. A document does not prove anything.
Quick
A Spike is quick. A Spike is usually time-boxed, to as short a period of time we think is feasible to answer our question. That period of time should normally not exceed a day or so.
Brute-force
A Spike will not generate any production code. A spike can be a design session in code, just enough to prove that the design will work. It can be a technology investigation, just enough to see if that library will do the trick. All code from the Spike will be thrown away. It’s about learning, not production.
Rare
I know, that wasn’t in Ron’s definition. Just an additional remark. Spikes are rare. They occur only very infrequently. Once every couple of sprints sounds about right to me. That might decline with the age of the project, as Spikes are particularly useful to remove uncertainty on technical design early in a project.
In practice
When an occasion comes up to introduce a Spike into a sprint, you do the following:
- Reconsider: Do you really need to investigate, or are you just scared to commit to an actual, value delivering, user story because you don’t know the system very well?
- Reconsider again: Do you really need to investigate, or are you just scared to work together with the rest of the team without someone handing you a detailed specification?
- Define the question: ‘grooming’ a Spike means that you clearly and unambiguously define the hypothesis that you need to have answered by the spike. This is like the Spike’s Acceptance Criteria. That means clearly defined, and preferably having a boolean (yes / no) answer. Agree what further actions will result from a ‘yes’. And from a ’no’.
- Define the time-box: To answer this question, what size investment are we prepared to do? Keep it short. A day is long. Sometimes long is needed. Sometimes.
- Prioritize: The Spike is on your backlog. You prioritize your backlog.
- Execute: Code to find your answer. Stop as soon as you have it. Stop if the time-box expires.
- Deal with the result: That’s the action agreed upon earlier. A timed-out Spike also is an answer to that question (’too expensive to find out’), and also has an agreed upon action.
Have you done a Spike recently? How did that turn out? Did you get your answer? Or a time-out?