What Is Spike In Agile

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.

What are Spikes in Agile?

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. 

When to use spikes?

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: 

• The team does not know where to start or which approach to use. 
• There are several options, and the team is unsure of which one to follow. 
• Some groundwork is needed to work on the user story estimate. 
• The team is not sure about whether the solution they are considering will give the required results. 
• The team needs to know more about a modern technology or tool and find out whether using it is feasible. 
• The story has technical risk, and the team needs to work on a prototype to mitigate the risk involved. 

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.

Types of Spikes

There are basically two kinds of spikes 

1. Technical Spikes, where the team investigates the possibility of using new technical options, and 
2. Functional Spikes, where the team ponders on the impact of adding new functionalities to the product or checks out to see whether some features under consideration add value and fit the user needs. 

Who uses the spike?

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. 

Benefits of spikes in Agile 

A spike is a very useful approach that offers many significant benefits: 

1. It removes any uncertainty around a user story or feature 
2. The team can work with clarity and coherence, without having to implement tasks that are not defined properly. 
3. It gives enough knowledge to move ahead with confidence instead of wasting time seeking solutions to stories that are not mapped out properly. 
4. Estimates can be accurate, allowing proper scheduling of releases. 
5. Any uncertainty or risk can be mitigated. 

How NOT to use the Agile spikes?

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!  

• A spike could last forever, eating into the time set aside for the sprint. To ensure that this does not happen, time-box every spike. 
• A spike that is too short will not produce the desired results. Give it sufficient time so that the team can gather the required knowledge before proceeding further. 
• A spike is a pause on the implementation of the story. A common mistake is that the story continues to be implemented while the spike is under way. This is counterproductive and can result in rework and wastage of time. 
• It’s easy to lose focus on the topic and go in other directions. Keep the spotlight on the topic you are spiking, and do not digress. 
• In cases where the topic is completely unknown, some refinement is needed before you spike on a specific issue. 
• It is important to delve into the issue in sufficient detail. Surface information is always inadequate, and the very purpose of the spike is to dig deep. 
• Some teams make the error of having a sprint that is entirely comprised of spikes. Avoid doing this as there will be no visible progress, and this can greatly hamper team morale. 

In summary 

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.