What to know about agile spikes

Agile software development emphasizes rapid adaptation and value delivery, facilitating quick responses to changing project requirements. Utilizing cross-functional teams in iterative sprints, Agile minimizes disruptions and enables constant software improvements. Particularly well -suited for low-code development, Agile aligns with the philosophy of swift application changes, catering to both seasoned developers and citizen developers. The Agile process follows a cyclical pattern, encompassing planning, design, development, testing, deployment, and review phases, breaking work into user stories that articulate software features from an end user's perspective.

Spikes can be useful tools, but it is worth recognizing that they do not, by themselves, deliver value. Placing too much emphasis on Agile spikes—particularly in situations where standard discussion and experimentation may more easily resolve the issue—can hinder projects from moving forward. For the best possible results, consider the following guidelines for Agile spikes:

Be careful about the timing
By their very nature, spikes represent uncertainty, which makes them a risky prospect to plan for when they are included in the same iteration with their resulting stories. In most cases, spikes should be separated out. That said, if the spike is small, straightforward, and likely to yield quick results, combining both tasks in the same iteration can be efficient.

Hold spikes to the same criteria as standard user stories
As with any other stories, Agile spikes should be placed in the team backlog, their size should be estimated, and they should be allocated to an iteration. While spikes may not produce working code, their output must still be quantifiable and demonstrable. It should provide the information needed to confidently identify and size subsequent stories or determine the best technical approach. The product owner should allow only spikes that meet their acceptance criteria.

Use spikes sparingly
While every user story in Agile development carries at least some uncertainty, it does not necessarily mean that Agile spikes are always the best answer. Spike-like activities are powerful tools for resolving technical and functional issues but may at times be less effective (and more resource-intensive) than simply collaborating as a team to discover a solution. Spikes are most appropriate when teams are faced with high uncertainty or numerous unknowns.

Always time-box Agile spikes
The Agile methodology is only agile only when it can move forward, which is why spikes must be governed by clear deadlines. Once the deadline arrives, teams will need to report whatever findings they have and then determine the next course of action (even if that means following up with another time-boxed spike). Aim for a single, clear question to answer in each spike to maintain focus and effectiveness.

The duration of an Agile spike depends on the needs and capabilities of the team and the requirements of the project. What is most important is to recognize that too deep of a dive into the research can, take time away from other tasks. Not even the most prominent features are worth the wasted resources that go into an over-engineered solution. Instead, a better strategy is to go lean with the time allotted to a spikes—often a single day of research—and to remain flexible enough that additional spikes may be employed if needed.