Are spikes the underestimated piece of the puzzle for less risk and more quality? They are often met with resistance, but could be precisely the tool that we often lack in agile software development.
What exactly are spikes?
Spikes are special user stories that aim to clarify uncertainties and risks at an early stage. They are used for exploration, validation and decision support before the actual implementation begins. Unlike regular implementation stories, they do not lead directly to a deployable product, but provide essential knowledge that enables secure and efficient implementation. They are usually designed as a timebox in order to quickly gain knowledge. If a final evaluation is not possible during this time, the risk must be dealt with in another way.
The added value of spikes: minimizing risks in advance
- Minimize risks at an early stage: Imagine your team is working on a complex implementation story that requires a new technology. Without prior evaluation, it could turn out that the chosen approach does not work. This leads to costly abandonment and lost time. Spikes offer a solution to better assess the risk and deal with it at an early stage. Valuable resources will then not flow into inefficient solutions.
- Avoidance of unpaid and unfinished work: Evaluations integrated into implementation stories harbor the risk of the story getting out of hand and not being completed in the sprint. Spikes enable a clear separation of evaluation and implementation so that your implementation stories remain focused and investments are only made in validated approaches. This saves time and money.
- Focus on clearly defined, small goals: Spikes make it possible to set clear, small goals that allow the team to work in a focused and efficient manner. They prevent the team from getting lost in too many alternative solutions.
Examples of spikes with clearly defined targets:
- Technology evaluation: "Checks whether Framework X is suitable for implementing the new user interface."
- Prototyping of a new feature: "Create a functional prototype for Feature Z to check the technical feasibility."
How spikes should not be formulated:
- Target: "Investigate how the new technology X can be integrated into our system." Problem: Unspecific, too comprehensive, no clear results.
Why spikes are sometimes unpopular with product owners
As product owners, we want an MVP (minimum viable product) for every story. A story without a direct contribution to the product feels like a waste. We would like to see such evaluations as part of the implementation story. However, we should be aware that without spikes, the risks must be included in the team's complexity assessment. This "risk buffer" is not transparent for us and cannot be planned well. Alternatively, the team estimates based on unvalidated assumptions. If these do not apply, rework or costly changes to the solution may be necessary.
For the team, evaluations do not belong in implementation stories
The integration of evaluations into implementation stories is also not useful for the team. It can dilute the focus and go beyond the scope of the story, resulting in the sprint goal not being achieved. Spikes help to avoid this by clearly separating the evaluation from the implementation process and making it more efficient.
Spikes - added value for product owners and teams
Spikes are not an additional burden, but a valuable investment in the success of your implementation stories. They minimize risks, ensure targeted development work and lead to faster, higher quality results. By integrating spikes into the development process, you gain planning security and increase the quality of the delivered software - a win-win situation for everyone involved.
