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.
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!
Spike is for gathering information or answering a question rather than produce a “done” product.
I have done this as a part of backlog grooming rather than calling this as a spike.
What is the origin of the Spike word?
Like driving a literal stake into the ground, a Spike Solution is a quick deep dive into a problem. (See also http://wiki.c2.com/?SpikeSolution)
Thanks for the question!
Very clear and meaningful article
I think Spikes nears to POC or proof of concept
It can, but usually a Spike is discovery or research into an unknown. It may involve some small dev or test builds of code.
I see a POC as more of building out a whole system or app to see if it works to solve the problem.
A Spike is a small effort, where a POC is larger.
A Spike should NOT become a Proof of Concept (POC). Spikes should be small, infrequent, for the purpose of answering some questions about the direction to go in.
So a team may need to run one or more spikes to achieve a Proof of Concept (PoC).
And a POC may be required before defining an MVP.
Can a story taken from the backlog and put in the sprint while there is a spike created against it? It sounds like the uncertainty the spike is trying to remove should be out of the way before taking the story in the sprint.
Spike results can be reviewed by all of the team member. Person or pair who picked the spike card can host a session for sharing the knowledge to team members.
I think this advice is too thin to be a recommendation of what to enter for a spike. I also think it’s poor practice to not time-box a spike. You’re implying a blank cheque to do a piece of work, which if it becomes big enough would be a candidate for an initiative.