The importance of Spikes in Scrum | David Tzemach
Updated: Mar 3, 2022
In any development process, there are situations where the team must perform preliminary research about some aspects of the work. This improves their ability to understand the scope of work, determine work estimations and gain confidence in the suggested solution.
In Agile software development, the team uses a special story called a "Spike", that allows them to do the necessary research and analysis to reduce common development risks and uncertainty prior to producing the shippable product.
The origin of the name spike comes from Extreme Programming (XP), where “A spike solution is a very simple program to explore potential solutions.”
Spikes are used to research technologies and technical approaches to solving a problem within a specific domain or when there is a high level of uncertainty as to how the end user will interact with the application.
Spikes will also help the team to assess the quality of a suggested solution, which allows the team to understand how best to organize the work, or which is the best approach.
Common Use Cases for Spikes
When the team needs to do preliminary research to learn new technology needed in order to develop a user story (such as a new development tool or new supported platforms).
When the team cannot estimate a user story appropriately and thus needs to analyze the implied behavior that will assist them to understand the real work effort to deliver the user story.
When a user story contains significant functional risks that can affect other components. Therefore, the team needs to understand how the new functional behavior should be developed to reduce the risk in areas identified as potentially problematic.
Guidelines for Using Spike Stories
Although spikes are very important for the Scrum development team, they do not provide direct value to the customer. In the next few paragraphs, I will provide some guidelines that work effectively in my teams:
You should be able to demonstrate its results
A Spike may have one of several outcomes, such as investigation results, proof of concept (POC) and sometimes just reduced uncertainty. Due to the importance of these outcomes, the spike story must be demonstrable to both the team and to any other stakeholders (like any other functional story) to increase visibility.
Make sure it’s time-boxed
Like any other story, spikes are added to the product backlog. Therefore, the spike should be sized and estimated for a max of 2-3 days (although some people may say that it can be estimated for a longer period).
Avoid planning for both the spike and the resulting stories
Spikes represent risk and uncertainty in one or more potential stories. Hence, I always suggest not to include stories based on the spike’s results as part of the planning session. First, complete the spike to gain more information and only then estimate the related stories.
Define a clear spike outcome
Before working on a spike, the team must include a clear definition of what they want to achieve at the end of their investigation (e.g. design sketch, a working prototype, etc.). By defining a clear expected outcome, the team can understand the boundaries of the investigation and see when the spike has been completed.
Do not use it to nail down all details
Spike stories should not be used to figure out the little details before you start working on a specific feature/story. Spikes should allow the team to gain confidence and reduce risks. It should not be used for researching solution details that could be figured out during the implementation process.