Spikes: Purpose And Usage

Spikes. It’s part of my blog’s name: Spikes and Stories, and it’s a bit of word play, which I’ll explain at the conclusion.  Because of this, it seems only appropriate that I pay homage to spikes and explain how I’ve used them with teams.

They have their origins in Extreme Programming (XP), and I define a spike as:

Work within a sprint that will not deliver any value itself.  Instead, it will create knowledge that may be instrumental in doing or estimating future work.

Why call them spikes?

I don’t know.  I’ve seen several conflicting stories on the origin of the term so I’ll not make it worse by picking a side or by making up another origin story.  Nonetheless, I think most of us will agree that it’s not a very intuitive or descriptive name.  Whatever their origin, their usage is a more interesting story.

Should teams estimate spikes as they do stories?
Some say they should be estimated, and they say so for a few reasons:

• How do we do velocity-driven planning if we don’t estimate spikes?
• So the team gets credit for the spike in their velocity.
• They shouldn’t be penalized just because they don’t know everything.
• If velocity is a measure of how much work a team can accomplish, credit should be given.

However, I disagree. I say no.  Spikes should not be estimated, and as with so many other things in agile, it comes back to our manifesto which states:

Working software is the primary measure of progress.

We’ve establish that spikes create knowledge but deliver no working software, and if working software is what we measure, then a spike should not be estimated.  Here’s some other supporting reasons:

• Spikes should be used sparingly. If they’re used often, it could be a sign of problems.  By not estimating spikes it reinforces this message.
• As I stated in a previous blog post, knowledge gathering is more important than task completion.  Some measure of learning is baked into every story.  We don’t need to call out every one of those circumstances with a spike.
• If a team uses the velocity argument, it could be a sign that the organization or the team is overemphasizing velocity. Digging into the root cause here could yield more fruit than simply estimating spikes.  After all, velocity is just a metric, and those tend to be abused anyway.

If not estimated as stories, how do we account for them for planning or for capacity purposes?

Here’s three of the most common ways I’ve used:

• Time box it. Give the team x hours to gain whatever knowledge they can.  (Usually no more than 8 hours.)  This way, you know how much time you’re losing toward gaining this knowledge.
• Give the team very clear, concise, and bounded questions to answer that will conclude the spike.
• Both.  If all the poignant questions are answered and time remains, the team can either conclude the spike or can finish out their time box by answering other tangential questions.  Conversely, if they run out of time without answering all questions, we’ll discuss the value of adding more time on the clock.

No matter what method you choose, pay close attention to spikes.  When the knowledge gathering is interesting, it can be tempting to spend more time than prudent working on them, which will be time lost toward creating working software.

So what does scrum say about using spikes?

It doesn’t. As I mentioned at the start, we borrow spikes from XP.  Spikes aren’t a part of the scrum framework.  They never have been and likely never will be.  It’s simply something we borrowed from another practice since it fit nicely into our universe.  Experiment with them and find what works best for you.  I only give you best practices from one scrum master’s play book.  Mine.  Your mileage may vary.

I explained at the start that I wanted to take a few minutes to pay homage to my blog’s name.  If you weren’t familiar with spikes at the start, I hope you are now, and I hope the name makes more sense.  Spikes and Stories:

By way of the knowledge I’ve gained (spikes), I want to share with you my experiences (stories).

Credit goes to my creative co-worker Paul for the name.  Thanks, Paul.