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.

Post to Twitter Post to Plurk Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to MySpace Post to Ping.fm Post to Reddit Post to StumbleUpon

Comments (3) to “Accounting for Spikes”

  1. Good article, George. This is a subject that we took on as team members, I teach this in Scrum classes, and will be discussed in my upcoming book, Managing Software Debt.

    As an additional piece of content on the subject, I wrote a blog entry a while back that provides a similar, if not the same, point of view as you discuss here. Thought you might be interested since it also discusses research and tracer bullets along with spikes.

    http://www.gettingagile.com/2007/10/22/research-spikes-tracer-bullets-oh-my/

  2. Interesting article –

    When you estimate a project you have a number of days development work with a margin for error.

    The outcome of a spike should be it reduces the margin for error at the cost of a little extra work. I think it’s reasonable to consider this as a valid development output as greater certainty over dates when a project can be delivered is of tangible value to a business.

  3. That’s true, but that’s a fairly small value to the business. I found this quote, today:

    “The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them.”

    Steve McConnell, Software Estimation: Demystifying the Black Art

    See also Tom DeMarco’s article where he says

    Strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value.

    All in all, estimation is not worthy of the attention it generally receives.

Post a Comment
*Required
*Required (Never published)