What is a Spike in Agile
What is a Spike? A spike originates from extreme programming and was traditionally a little piece of code, proof of concept, that we would create in order to unlock complexity and to answer a question about something that we weren’t sure about. Today Spikes are used to apply to any form of research or experimentation that a team might need to do..
Spike stories are used to determine a specific piece of information or find the answer to a single question. Without this information, the user story or task cannot be moved forward as was originally intended.
Because Spikes are used for individual questions, the information gathered, or answer to the question, needs to be informative and precise. There is no room for vagueness. In a case where you need answers to multiple questions, it is always best to split the Spike up and tackle each one of them individually. Finding the answers to the individual questions helps define precise information, that in turn, will allow you to plan and move a project forward in a more informed direction.
Who uses a Spike?
Developers are the owners of the extreme programming – or XP – who use the Spike. They work on a Spike story to determine the best approach to solve or put new technology in place in the upcoming sprint. However times have changed and the use of Spikes is now applied by anyone, or group of people, working on a research project.
Are all Spikes the same?
No, not all spikes are the same, there are two main types of Spikes that you should familiarise yourself with. A technical Spike and a functional Spike. Let’s take a moment to find out more about these two types:
What is a technical Spike?
A technical Spike is a type of Spike that helps you to identify and evaluate options to reduce risk by selecting a technical approach.
These Spikes are the architecture decision process and the design decision process. But in Spike, we go beyond research to build the smallest solutions that are functional enough to address the criteria.
Okay, so what is a functional Spike?
These are used to address the overall solution or behaviour to meet customer needs. This gives us a “bigger picture” approach to problem solving.
Why use Spike in agile?
There are some clear benefits to implementing Spikes in Agile. Not only will it help break down any uncertainty but they will in turn create more clarity on where the story is going and the path ahead. Spikes also help to avoid any overestimation and give the team more control over delivery. It’s the perfect way to ensure that you’re in control and remain in control.
Spike assists in minimising any uncertainty and risks in the project or product. When you break down the epics into smaller stories/Spikes, it provides the right solution to a need or a problem. Making decision-making much easier.
It also delivers the technical research results during the time-boxing process and provides collective ownership and shares the responsibilities.
But how do you know when a Spike is necessary for your team? That’s simple! A Spike can be implemented whenever uncertainties and risks arise. It can be incorporated when the user story is very large or complex and during the necessity to break down the user story.
A Spike can also be used when time-boxing is required and at the time of researching requirements.
What’s the end goal of a Spike?
The end goal of a Spike is not to find the solution to a project, but to help estimate how long a project or story may take to complete. This will benefit the team by helping to increase their understanding of the user’s story. This then helps cut down on wasting time and resources. With each Spike, the team will need to dive deeper into the story rather than merely scratch the surface. This allows the team to make a far more accurate estimate.
To wrap it up, Spikes are user stories used in scrum projects or products that are decided by the product owner. These user stories are then passed on to the developers. The larger user stories get broken down into smaller user stories, this makes them more manageable. Spikes instil permanent trust, visibility, and predictability of the product or project roadmap and are a vital step in your success planning.
