Why Agile Spikes?
How Agile Spikes help to Improve your Agile Product Delivery?
Learn what are spikes in Agile and how Scrum teams use Agile Spikes to estimate the product backlog.
What are Spikes in Agile?
A spike is a user story for which the team cannot estimate the effort needed. In such a case, it is better to run time-boxed research, exploration to learn about the issue or the possible solutions. As a result of the spike, the team can break down the features into stories and estimate them.
The term comes from the meaning of the object — a spike allows you to go deep on a problem. A common analogy used is rock climbing. When you cannot go any further, you drive a spike in the rock. It doesn’t allow you to climb more also, but it enables you to build the path and to plan your way. It is the same in Agile development. Agile Spike allows you to go further.
When to use spikes?
The spikes must be identified only after the product backlog refinement. If besides refining the user story or user stories, there is still a lot of uncertainty around the estimations. There are four primary situations in which I recommend the use of spikes after the backlog refinement:
- There are multiple options; the development team needs to perform further trials to find which one is the most suitable.
- The development team doesn’t know if the solution they are considering will give the expected results or not
- The team has no idea how to approach the problem
- The team needs to do some initial work to be able to estimate the user story or user stories.
Let’s take an example: Imagine your team is working on a software that will make the roof of old cars to be convertible. During refinement sessions, they noticed that there are several options:
- change the roof with new technology, but this is not an option accepted by the car enthusiasts
- implement an automatic foldable roofs
- a hard top which you remove it by yourself
- Build the roof from a material like a glass that opens. It is not wholly convertible, but it opens
Can I use multiple Agile spikes for one story?
Yes definitely! I encourage the teams that I agile coach to do that:
- one agile spike for research of possible solutions,
- one agile spike for the trial and errors of the possible solutions
- one spike for estimating the implementation.
All three spikes will be in 3 different sprints.
Types of Agile spikes
There are two main types of Spikes in Agile:
- Technical spikes — when the team investigates technical options, the impact of new technologies, etc.
- Functional spikes — when the development team evaluates the impact of new functionalities to the solution. Or how certain features fit the business need.
On the car example, the team will run both technical and functional spikes:
- a technical spike to see which of the four options can be supported by the systems of the old cars
- a functional spike to see if the new functionality is suitable for the way the old cars are being used.
Benefits of spikes in Agile
- Breaks down uncertainty
- No pressure to do something, but there is a pressure to don’t go undefined forever
- Always clarity on where you are heading
- Avoid overestimation of stories due to uncertainty
- Close to reality estimations because you split the risk of the certainty
At the end of the OldCar spikes, the team knows which solution they will implement, in what user stories, and the estimation of the user stories to enable this functionality.
How not to use the Agile spikes:
- Go forever on an issue. Set timeboxes.
- Give enough time to have results.
- Don’t implement the story while doing spikes
- Keep it focused on the topic you are spiking.
- Sometimes the topic is unknown. Do some refinement before, then spike it on a specific issue
- Dive deep into the story. Don’t stay at the surface because you want to estimate it correctly
- Don’t have a sprint made of spikes
Conclusion
From my perspective, Spikes in Agile are aimed to help the Scrum Team to have control over the delivery and to commit to the sprint goal. Spikes give permanent trust, visibility, and predictability to the product roadmap. You can have spikes on features or user stories.
You may also read:
