Sometimes the most optimal solution to a problem remains unclear, and there could be multiple reasons for it: perhaps a problem is particularly unique, with no known solution, or there could be a lack of clarity pertaining to which technology — including enterprise solutions for business — would efficiently handle it. This is a time for experimentation — to validate your initial hypotheses and choose the right foundation for your long-term solution. And that’s exactly what spikes in Agile are all about.
So in a nutshell, spike solutions or “spikes” may be thought of as small technical investigations or experiments that aim to clarify the most appropriate answer to solving critical development problems. These will often take the form of core code trial runs or simple prototypes, and could be needed for a wide variety of reasons. With this in mind, when it comes to spikes, below are the most important things to remember:
- They should consist of the simplest possible implementation
- They should take as little time as possible to complete
- They should not be expected to produce a working feature
- They should be estimable, demonstrable and acceptable
Right Way to Spike
There are three main types of spike in Agile: research spikes, architectural spikes and refactoring spikes, and depending on the problem being addressed, these may be further subdivided into technical and functional varieties.
Technical spikes in Agile
Technical spikes are used to evaluate the potential impact of different technologies — and thus tend to focus mainly on research and code. Though somewhat similar to the architecture decision process, when working with technical spikes, the team goes beyond simple research to build the minimum solutions that are needed to address the evaluation criteria. In this way, they seek to experiment with a new technology and gain more confidence in a desired approach before committing new functionality to a timebox. Technical spikes may be employed in any one of the following situations:
- Understanding if a new technology will solve the problem
- Evaluating the impact of a new technology
- Making the build vs buy decision
- Determining the load impact of a feature
- Establishing current usage patterns
- Understanding the potential performance of a brand new feature
Functional spikes in Agile
When working with functional spikes, on the other hand, the team is primarily concerned with the user’s interaction with the system. As a result, they rely above all on mockups, page flows, prototypes and wireframes when attempting to:
- Determine the interaction with a new feature
- Break down a user story into manageable components
- Organise work
- Identify risk factors and other uncertainties
Spike user story example and timeline
With all of this in mind, a spike story in Agile will usually follow the traditional user story format:
As a <type of user or system>, I need/want <some goal/action> so that <some reason, benefit>
Consequently, a good example of a spike user story would be the following:
As a site manager, I want to see forecasted data for my sales vs expenses so that I could make some predictions for forward planning.
This could lead to both a functional and technical spike:
- Technical spike: The team should research if machine learning is a quick and reasonable option to use for the forecasting module
- Functional spike: The team should prototype a UI for visualising forecasted data and obtain user feedback to decide on the best approach
But how long do these spike solutions take to create, and are they included in our regular iterations? Well, interestingly enough, the second answer follows directly from the first one!
Because when working with spikes in Agile development, we are unavoidably dealing with a vast amount of uncertain factors, spike creation times can vary greatly and it is impossible to accurately predict how long this process will take.
Still, not having spikes is certainly not a feasible option, as you risk shrouding the project in a misty sea of uncertainty that could prevent you from spotting the technical iceberg ahead! Consequently, as a precautionary measure, many encourage the creation of timeboxed spikes. In this way, at any point throughout the timebox, the team can decide if they have done enough to tackle the problem — and if by contrast the timebox is fully utilised, they can revisit the original purpose and from there decide how to proceed. In our own case here at SPG, instead of including spikes in our timeboxed Sprints, we tend to work on them before Sprint planning, or between iterations, if that makes more sense.
As Kent Beck, the creator of Extreme Programming, once famously said, “spikes are good for when you are knowledge limited, not time limited!”
When to Use Spikes
A true legacy of Extreme Programming (XP), spikes in Agile are still very much relevant today, as they may also be seen as calculated investments by the Product Owner to thoroughly analyse a problem before attempting to build a solution. After all, the Product Owner intentionally allocates a little bit of the team’s capacity ahead of when the story needs to be delivered so that when the story enters the Sprint, developers know what needs to be done. In this way, spikes are first and foremost used to try to mitigate technical risks.
The technique is often said to be needed when researching product requirements or when user stories are too large or complex, but for those who are less acquainted with spike in Agile terminology, here are a few simple examples of when spike solutions may be necessary:
- When developers are dealing with new hardware or software technology
- When working on complex legacy systems
- When confronted with poorly documented third-party libraries
- When it is important to identify the most optimal form of implementation (be it an algorithm or underlying technology) from a variety of different options
Pros of Spike Solutions
Despite anything to the contrary, taking the time for Scrum Spike tests is undeniably a great investment in the planning process, as they enable developers to gain a much better understanding of the problem in order to make the right decisions that will benefit both the project and product. The following benefits are also apparent, as spike solutions:
- Provide clarity on the project’s direction of travel
- Build shared responsibility and collective ownership when making decisions
- Greatly minimise project risks and uncertainties
- Ensure the right solution to every problem
- Avoid story overestimations
- Can save money, time and other resources
Cons of Spikes in Agile and Scrum
It is important to remember, however, that especially when spikes are misunderstood or incorrectly employed, they can also lead to development issues. For one, because unlike user stories, spike results produce maximum information with minimal code, they should only generate the required data to resolve the issues in the stories that drive them. Next, developers must remember that any spikes sitting in their backlog represent actual development risk, so they should aim to resolve them as quickly as possible to keep development on track to success.
Aren’t Spikes the Same as Prototypes or Proof of Concepts?
While spikes, prototypes, and proof of concepts (POCs) may seem similar, they serve different purposes within Agile methodologies:
- Spikes are research-driven tasks aimed at reducing uncertainty and gaining knowledge. They help teams understand requirements, evaluate approaches, and mitigate risks before implementation.
- Prototypes are preliminary versions of a product. They focus on the visual and functional aspects to validate ideas and gather user feedback without considering scalability or performance.
- Proof of Concepts (POCs) demonstrate the feasibility of a concept or technology. They test specific functionalities or technical aspects to prove that a solution can work as intended.
To summarise, spikes focus on investigation and learning, prototypes emphasise user interaction and design validation, and POCs aim to prove technical viability. Understanding these distinctions helps teams choose the appropriate approach based on their goals and challenges.
Conclusion
In spite of the chosen nomenclature, spike solutions should not be taken to mean a final product or its functional parts. Instead, they are simply investigative experiments which enable developers to do away with technical risks — and thus properly estimate the time and costs that are associated with every feature.
