Agile Spike, who should enter it, and how to word it?

What’s a Spike? Who should create it? And what should it look like in VersionOne? (Or in Agile Central, Pivotal Tracker, HP AGM, Jira, or your ALM tool.)

Excellent questions! I thought I’d share my thoughts on the topic:

What’s a Spike?

Sometimes a story is too large or overly complex. Perhaps the implementation or a 3rd party tool or library is poorly understood. The team can’t estimate the story. Perhaps we’re unsure if we’ll be able to complete the story due to some potential blocker.

In these cases, we might want to build a functional or technical experiment to figure it out. We might want to look into something for a day. We might want to look up alternatives. Do some googling. Do an experiment with some other library or software package. Consider alternative refactoring paths.

These are “spikes”. You can call them research spikes, or architectural spikes, or refactoring spikes if you wish.

A spike as an investment the Product Owner makes to figure out what needs to be built and how the team is going to build it — in advance of actually building it. The Product Owner allocates a little bit of the team’s capacity now, ahead of when the story needs to be delivered, so that when the story comes into the sprint, the team knows what to do.

Therefore:

How to Enter a Spike

If the spike only takes, say, an hour or two, maybe we don’t need to track it in our ALM tool. If it’s larger than that, you should enter it into your backlog.

How would a BA or Product Owner write up a spike? The cocky answer is to say “make your tech lead enter it”. A more serious answer would be that the technical story format would be good:

In order to <achieve some goal> <a system or persona> needs to <some action>.

Example: In order to split the collection curve wizard story, the tech lead needs to do some detailed design. (Just enough to split the story.)

Example: In order to estimate the “user connection report” story, the tech lead and BA need to research capabilities of MSTR and have some conversations with the PO. (Just enough to estimate the story.)

I like to start the name or title with “SPIKE:” to make them stand out in the ALM tool. Using a tag or a label could work as well.

Time-box your Spikes

Teams should agree that every spike is, say, never more than 1 day of research. (For some teams this might be, say, 3 days, if that’s the common situation.) At the end of the time-box, you have to report out your findings. That might result in another spike, but time-box the experiments. If you weren’t able to answer the question before time runs out, you must still report the results to the team and decide what to do next. What to do next might be to define another spike.

You might say “I think there’s a bug in the app server… there’s no way I can hear back from their support within the time-box.” The timebox is effort, not calendar time. So, the spike can be about recreating the problem and providing enough info for the support group to look into it.

It’s also best if a spike has one very clear question to answer. Not a bunch of questions or an ambiguous statement of stuff you need to look into. Therefore, split your spikes just as you would large user stories.

You don’t have to use the whole time-box. For example, if it’s an estimate that you were after, do just enough work to give the estimate and stop.

By the way, I don’t estimate spikes, but that’s another blog post.

There you have it, an answer to what’s a spike. More than you ever wanted to know about spikes!