Accounting for Spikes
The term Spike Solution is associated in my mind with the early days of Extreme Programming. I’m sure that it is built from prior ideas, as everything seems to be. If the term and the concept it describes predates the Chrysler C3 project (Ron Jeffries mentions using it there), I’ve not yet uncovered it. Ron credits Ward Cunningham for the term. I’m sure there are predecessors, even if not expressed as distinctly.
The goal of a spike solution is to answer a question. For example, a spike may be used to test the feasibility of an algorithm or 3rd party library. It may be used to explore design alternatives for solving a sticky problem. It’s called a spike because it drives all the way through the problem, but as narrowly focused as possible. It’s not a complete implementation. Associated complexity that is secondary to the question is likely stubbed out to reduce the clutter and increase the focus.
The output of a spike should be the answer to the question. It’s important to articulate the question as clearly as possible, as that helps in answering it. Sometimes “as clearly as possible” just isn’t very clear, though. When we don’t know something, we often can’t describe what it is that we don’t know.
We also often don’t know how long it will takes us to learn something that we don’t know. A spike is time-boxed so it doesn’t become a permanent research project. If, at the end of the timebox, the question is still unanswered, then you have a decision to make. You may decide to spend more effort on the answer, or to abandon it and try something else.
I frequently hear Scrum teams discovering the concept of a spike, particularly when they’re having a hard time estimating items in their product backlog. Sometimes they have an incomplete notion of what a spike is–hence the description above. Other times they wonder about how to account for them in the Scrum process.
If it takes more than minimal time and effort, I usually put a card on the wall (i.e. in the sprint backlog) to make the spike visible. It’s different from a story card, however, in that it has no value to the system. Sometimes people want to put them into their velocity to get “credit” for the work. It’s not an output of development, just a bit of work to aid the team. I reserve velocity for work delivered, not for work expended.
Sometimes people worry that they won’t correctly estimate the team’s capacity for work in a sprint if they don’t keep track of them. I would not worry too much about the “accounting” for spikes. They’re just part of dealing with the uncertainty of creation, though more visible than some other such parts. If spikes become a significant drain on the team’s productivity, I would ask myself “why is this happening?” Otherwise, I wouldn’t worry–they’re just part of the noise in the velocity data.
In fact, I would not generally use a spike just for the purpose of better estimation. It may be better to just do the story. If the estimation is wrong, well, that’s OK. That’s why they call it an estimate.