Uncertainty is an inherent part of the complex domain of software development. To reduce uncertainty, we made it a part of our custom agile software development methodology. We plan the next sprint for each team by picking the top-most items from the backlog and giving a rough estimate. However, sometimes a new feature request is to be implemented and well defined, but nobody in the team feels really comfortable estimating the Story Points (SP) required to complete it. Now the question is, how can we overcome this feeling without jumping blindly into the development and risk failing the sprint due to wildly underestimating the feature in question? The answer is:
Spikes
A technical spike is a time-boxed period of investigation and exploration that is used to answer specific questions or address technical challenges. These spikes can be an important part of the development process, as they allow teams to explore new technologies, evaluate potential solutions, and make informed decisions about how to proceed with a project.
Technical spikes can be used for a variety of purposes, including:
- Researching new technologies or tools that could potentially be used on a project
- Evaluating different approaches to solving a specific technical challenge
- Prototyping a solution to a problem in order to better understand the requirements and feasibility of the project
- Gathering data or performance metrics to inform decision making
One of the key benefits of using technical spikes in an agile development team is that they allow teams to make decisions based on real data and experimentation, rather than relying on assumptions or guesswork. By dedicating a specific period of time to investigating a problem, teams can gain a deeper understanding of the technical landscape and make more informed decisions about how to move forward.
Another advantage of using technical spikes is that they can help teams avoid wasting time and resources on solutions that ultimately don’t work. By dedicating a small amount of time up front to explore different options and evaluate their feasibility, teams can avoid committing to a path that may not be viable in the long run. This can help teams stay focused and avoid costly detours or dead ends.
It’s important to note that technical spikes should be carefully planned and managed in order to be effective. Teams should define clear goals and objectives for each spike, and should establish criteria for success in order to determine whether a particular approach is worth pursuing. Additionally, teams should ensure that they have the necessary resources and expertise to carry out the spike, and should carefully track and document the results in order to inform future decision making.
In our particular case, we consider spikes in the same class as new features. A Spike is usually split from a feature request and time boxed to allow enough time to comfortably answer all open questions and posed objectives of the spike, just as we would do for any feature request. Should the allocated time not suffice, we will stop, sum up the findings and rediscuss the issue, possibly even split into additional spikes. Even if it may sound negative, usually it is entirely positive as complexities were uncovered that have been unknown previously.
Overall, technical spikes can be a valuable tool for agile software development teams. By dedicating a focused period of time to exploring technical challenges and evaluating potential solutions, teams can make more informed decisions and avoid wasting time and resources on solutions that don’t work. By carefully planning and managing these spikes, teams can take advantage of their many benefits and stay on track to deliver high-quality software.
Benjamin Gröber
Author
