Purpose
As the team is creating software they will encounter times of uncertainty. There will be questions on how best to proceed. Perhaps it’s a decision of which design pattern to use, or which data storage technique is preferred.
In such situations one recommended practice is to use a “spike”. Spikes are short experiments, research or analysis meant to answer a question or make a decision. They are used to reduce risk and uncertainty. Spikes are typically not part of the development work itself.
And by short I mean hours or a couple days, typically 3 at the most. This is time invested to learn, not to develop a piece of the product.
Usage
Most often, before proceeding with a high risk or uncertain bit of functionality, the team will proceed with a spike. Typically this will be created and saved to the Product Backlog. Just like any other product backlog item, it is discussed and brought into a sprint by the team. Sometimes work will stop on an inflight story to perform a spike though this is less common.
The entire team should create and discuss the spike effort. What sort of research is needed? What sort of learning will reduce this risk? Are there design patterns we should consider? Should we use this off-the-shelf functionality or create our own?
Record this information into the spike and then work it like any other backlog item. Refine if needed and pull it into a sprint based on when that information is needed.
This is a team decision which includes the Product Owner. As it will not directly deliver customer value it needs to be prioritized appropriately against other work that does create value.
The Timebox
It’s important to understand that, if you are using story points, you do not estimate spikes. Spikes do not directly deliver customer value. The only items in the backlog that should be estimated are ones that deliver value. For a better understanding of story points, check out this article.
Remember that spikes are used to do some research, investigation or run an experiment. But we don’t want that effort to be boundless. We don’t want it to go on and on. So we time box spikes. Think of that time box as the initial time investment the Product Owner & Team is willing to make on the effort.
Not a Deadline
The time box is NOT a deadline though. It is the maximum amount of time spent before the team will discuss the spike again. Though they could discuss it beforehand if the spike concludes before the time box expires.
If the spike is not completed by the end of the time box the team has 3 options. It’s important that the entire team discusses this with the Product Owner and decides, as a team, to:
- Extend the time box. Use this option if the team believes there is a reasonable chance the effort will bear fruit if a bit more time is spent on the spike. Be cautious though, we don’t want the spike to become a bottomless pit of hours.
- Conclude the spike and proceed using what was discovered to date. Use this option if the team is relatively certain they can proceed with low risk using what has been learned.
- Kill the spike. Use this option if the team believes that even if more time is spent on the spike that no meaningful results will the attained. Remember that bottomless pit of hours? Kill the spike before that happens.
A Suggested Format
Here is the format that I teach teams to use. You can modify it to fit your specific needs but I believe it’s important to at least capture these 3 pieces of information.
- Purpose – why are we doing this? What do we expect to learn? Why should the Product Owner invest time in this rather than having the team work stories which directly produce value?
- Outcome/Deliverables – what will be known or delivered at the end of the spike? What decision can now be made? Will the team create additional user stories? There are many different things that can be identified here based upon the nature of the spike.
- Timebox – how long will we initially invest in this effort?
Again, this is my preferred format. Yours might be different but make sure to understand why this is important, how it will reduce risk or uncertainty or help the team make a decision and how much time will initially be invested in the spike.
Wrapping Up
I hope this helps you to understand spikes and their usage a bit better. They are useful techniques but should also be used sparingly. They are not a tactic to replace getting a proper understanding of the product needs and goals.
Please leave me a comment below with any questions or concerns with spikes and their usage.
If you liked this post and want to learn more about Agile, Lean or Leadership, please consider purchasing a book from my Recommended Reading page.
Until next time!
