A spike in Agile is a focused effort to address uncertainties and gather insights before committing to a full implementation. In a previous article on how to manage uncertainty, I already mentioned this and other techniques that are often used interchangeably, so I believe it’s worth knowing more about spikes.
In this article I’ll also cover the origin of this metaphor (including the answer directly from one of its authors), and its pros and cons. And finally, I’ll suggest how to add spikes to your project using Taiga.
Definition of spike
As stated by Ward Cunningham: a spike answers the question «What is the simplest thing we can program that will convince us we are on the right track?», i.e. it is a short-term and focused effort undertaken by the development team or an individual developer to gain knowledge and inform decision-making at a specific technical or design problem. Spikes are meant to provide answers or insights into areas of uncertainty, i.e. a workable framework, before committing to a particular solution.
Origin of the metaphor
I guess that the first time I read about spikes was in the book “Extreme Programming Installed” by Ron Jeffries (one of the authors of the Agile Manifesto), but unfortunately there are some discrepancies about the original meaning of the metaphor. According to a well-documented comment in The Agile Dictionary, a spike, like rock climbing, involves driving a spike (a piton) into the rock face.
Although it doesn’t directly lead to reaching the top, it facilitates future progress.
Photo by Fausto Marqués on Unsplash
But Ron Jeffries also describes it in another book, “Extreme Programming Adventures in C#”:
“Spike” is an Extreme Programming term meaning “experiment”. We use the word because we think of a spike as a quick, almost brute-force experiment aimed at learning just one thing. Think of driving a big nail through a board.
Whatever the actual metaphor, the meaning remains the same: “Spike solutions” are experiments “end to end, but very thin” that bring enough certainty to continue in a complex scenario
Jeffries himself gave me the answer with this tweet.
Example of a spike solution
Imagine you are asked to develop a number of reports based on different data sources, record formats, and final formatting. You’re not sure whether developing each report or creating a reporting tool. Run a short (time-boxed) experiment. Keep it simple, no more than one or two days working on it. You are looking at reducing uncertainty, not progress in your backlog. That’s a spike.
Spikes and estimations
I’m sure it’s not a coincidence that Ron Jeffries included Spike Solutions in the chapter dedicated to Story Estimations in his book “Extreme Programming Installed”. One of their reasons to exist is to help estimate the effort needed to develop a working story.
Remember the essence of the spike: you don’t know enough about solving some problem to be able to estimate it. Therefore, write some sample code, so that you’ll learn enough to make an estimate,
writes Jeffries about spiking for estimations.
Pros and cons of using spikes
As seen, spikes are useful to estimate tasks involving too much uncertainty. They are also useful for risk mitigation as they help in making informed decisions and adjusting our plans accordingly.
It is important to remember that spikes must be timeboxed in order to bring insights quickly, otherwise we may be losing focus. Also, remember that working on spikes doesn’t bring any value to our customers. It is the actual fully functional software that does.
Finally, although spikes can promote a learning culture, if we abuse them, they can undermine the iterative and incremental nature of Agile development.
How to plan a spike using Taiga
Imagine you’re asked to develop a new feature for your system, but it’s something that your team is not familiar with. Maybe it involves the use of a new technology, or there is too much uncertainty in the technical solution, or to implement a well-known solution at scale brings some difficulties that the team needs to explore in practice. Those are excellent scenarios to plan a spike.
You can do it as part of your sprint, as part of the story (some people call these tasks “research tasks”) or you can add them to a previous sprint so you have enough time to evaluate the conclusions. The key here is:
- Make sure you agree on a timebox or it may easily become a bottomless pit;
- Have a clear hypothesis of what you are trying to prove or learn, because at the end of your timebox you must end with enough insights to make a decision on the final solution.
If you are already using Taiga, there are some tips to apply.
You can use the Issues Module and create a custom type called “Spike” to distinguish them from the rest.
Then you can:
- Add [SPIKE] in the title itself. It makes it more obvious although it’s redundant.
- Add a tag. It will ease your searches or filters.
- Set the Due Date field depending on the timebox agreed.
- Once you are finished with the spike, you can decide to promote it to a Story (it creates a duplication in your backlog) or just forget about it.
In the description you should include some context, make explicit the timebox, and a short to-do list so you have an initial plan. But, as I said before, the key is having a clear hypothesis, that’s why I love this template:
- Belief or hypothesis: We believe that…
- Testing approach: We will…
- Expected outcome: We expect to…
- Success criteria: We will consider ourselves right if…
- Timebox and knowledge sharing: The spike will be timeboxed to [duration]. We will share the learnings with the team by [date/time].
In our example you could have something like:
We believe that… Apache Superset has all the features need to substitute Microsoft Power BI in the reporting system
We will… check the following features:
- Integration with PostgreSQL
- Advanced tables (including pivot tables)
- All the charts included in our dashboards
We expect to… have one sample for each test within the timebox
We will consider ourselves right if… we can give an order of magnitude to migrate all the reports and dashboards.
The spike will be timeboxed to [3 days]. We will share the learnings with the team by [due date].
Conclusion
Spikes are timeboxed experiments that help in estimating, designing, and planning future work by reducing uncertainties related to technology, architecture, tools, or approaches. There are some benefits, especially regarding estimations and risk management, but we must be careful because its overuse may reduce our agility.
