A term that has its origins in Extreme Programming (XP), an Agile spike is a metaphor for the short but all-important pause a rock climber takes while climbing, in order to hammer a spike into the rock. The spike serves as a foothold and is critical to the success of the journey, in much the same way that the Agile spike puts pause on a task while the requirement or user story is investigated more deeply.
In this article, we will help you understand what an Agile spike is, the types of spikes and how and when they can be used for maximum benefit.
Agile projects often start with just enough information to get started. Once the team finds that the project is viable, they do not wait till they have every bit of information at hand to begin work. The requirements are expected to unravel and be explored in depth along the way, even as the team collates information and gains more understanding on the product.
There are many times when this approach leaves the team struggling to estimate some user stories, simply because they just do not have enough knowledge on the task at hand. This is when a spike proves useful.
A spike is a type of exploratory story that is undertaken in order to gain deeper knowledge and reduce risks, or to understand the requirement in greater detail. It could involve further research and exploration, as well as design and prototyping. It increases the reliability of a story, allowing the team to break it down further with greater accuracy and run an accurate estimate.
Simply stated, a spike is a user story for which the team is unable to arrive at a consensus on the effort needed. They will then run time-boxed exploratory research and fill in the missing gaps, learning more about the uncertainties and the possible solutions.
Spikes are identified after the team completes the product backlog refinement. When they find that there is still uncertainty around the estimations, perhaps because the requirements are not clear enough, they will decide to use a spike.
Spikes can be used in the following situations:
A spike can be carried out on a user story, or on a feature, wherever the team needs more clarity. One story can even have multiple spikes: one for carrying out deeper research, one for working out solutions on a trial-and-error basis, and one for estimating the implementation of the story.
There are basically two kinds of spikes
The spike is used by the team to gain further understanding and collate information on an upcoming Product Backlog item that is lacking enough clarity. The Product Owner decides on the necessity for a spike and allocates some of the team’s capacity into working on the spike now to mitigate risks and avoid rework later.
A spike is a very useful approach that offers many significant benefits:
You’ve understood what spikes are and how they can be very useful during the Agile estimation journey. But there are several instances in which spikes can prove to be detrimental and can hinder progress. Here are some things to keep in mind, so that this doesn’t happen!
As we have seen, agile spikes help the team to gain a deeper perspective on any issues at hand, enhancing clarity and helping to gain control overestimates and delivery. Spikes assume critical importance in projects where there are multiple uncertainties, or there are many factors that are unknown.
When implemented correctly, a spike offers greater visibility into the problem at hand, increasing predictability in the product roadmap and improving outcomes.