In an agile development process, a spike is a term for a story that, unlike normal stories in a sprint, does not have an estimation attached to it. Developers use spikes to explore the concept, make library choices, and verify whether the design of the system is a valid solution. The goal is not to create production-ready code with full user workflows defined. Rather, it’s to produce a working prototype to investigate a solution. Teams can (and should) use spikes throughout the entire development process, but dedicating an entire phase of development for a new system to spiking can provide significant benefits.
Increased Knowledge of System Architecture
Perhaps the biggest benefit of a spiking phase is the knowledge the system developers gain from participating in the spiking phase. Oftentimes when a project begins, new developers who were not a part of the research and design phase join the project. Having the new developers participate in a spiking phase gives them a chance to explore the entire design of the system and learn all the systems that need to be implemented and integrated.
It also exposes the new team members to small business logic details that may often get overlooked. Additionally, the team can use this time to expose the system design to a fresh set of eyes. Developers who work on a project together for a long time can sometimes develop a mutual understanding of nomenclature or how things are represented in the design documentation that aren’t portrayed or fully expressed to outsiders. Allocating this time allows the team to fix any potential flaws and lets everybody working on the project gain a greater understanding of the system as a whole.
Development Without Pressure
Spikes inherently exist outside the normal process of agile development. This means they don’t suffer from the same constraints that standard stories do with estimation and point velocity in sprints. This relieves a lot of the pressure on developers to complete their stories within the estimated timeframe. Underestimations happen and don’t mean the end of the world. But, removing them for spikes gives developers time to fully analyze their prototyped solutions. Entire teams can take this time to collaborate and figure out shortcomings, find flaws, and if needed, design new implementations.
More Accurate Backlog, Estimation, and Implementation
All the discussion, prototyping, and analysis done in this phase culminate once spiking ends and the sprints begin. The knowledge the team gains from the spikes allows for more accurate planning around sprints and stories. When defining a backlog, project leads know more about what stories the project needs and what the implementation hypothesis should be for the story. When developers estimate the points for a story, the developers know which parts of the system require more work or less work. Additionally, when implementing these stories, the developers have a clear picture of how the system should be done.
A Spiking Phase Doesn’t Always Make Sense
Given all these benefits, one may ask: “Why don’t teams always utilize a spiking phase?” This comes down to a few things: the complexity of the project, the timeline, and the budget allocated for development.
Less complex projects with common workflows wouldn’t benefit much from a spiking phase as there is not much more knowledge of the system developers can gain from a spiking phase. Projects that must be completed in a short time can’t always take the time for a dedicated spike phase. Similarly, budget-constrained projects mean developers have to make the absolute most of their budget and may need to start working on features as soon as possible. However, if the conditions are right, a spiking phase can greatly benefit and enhance the development process of a project.