Sometimes we can’t move forward with stories because it’s unclear whether our proposed approach will work.
It’s time for a discovery spike!
When we do a spike, we’re not aiming to have usable code or artifacts as a result of it. We’re merely doing the least amount of research and discover to be able to decide a general course of action.
We might install some software, or write some code, to prove to us that it’s going to work. And then we might throw that code away. And when we work on the actual story, we product production quality code and artifacts.
I’ve noticed teams have different ways of managing spikes. I prefer to keep spikes outside of the backlog and sprint, since they don’t deliver direct value to the end product and end-user.
Some teams like to record spikes as a kind of meta-story whose job it is to make another story estimatable.
For example, if we can’t estimate Process Credit Card Payment because we’ve never used the Credit Card processing library, we create a Estimate “Process Credit Card Payment” spike and put it in the backlog. We then estimate and pull it into a sprint first, learn how the library works, and then return to estimate and implement the real story later.
Discussions for your team
- How do we decide when a spike is complete?
- What are some kinds of questions a spike needs to answer?
- How will we capture and share spike findings with the team?