Agile spikes are used during product development as a means to explore solutions for a user story for which the team cannot yet estimate a timeline.
When a team needs more information to develop a feature, a spike allows them to develop the means and methodology first, before committing to a defined user story. How product teams use the time provided by the spike is up to them, but most product managers will explore either technical solutions (the nuts and bolts of developing a feature) or functional solutions (how the feature will impact the final product or align to the product vision).
Generally speaking, a product development team will use spikes in Agile as a tool to crystallize requirements going forward. The common rationale for the use of a spike is that there are competing solutions for a particular feature. For the team to choose the right path in developing this feature, a spike is deployed as a user story in the roadmap and the time used for developing, testing, and finalizing solutions.
There’s no right or wrong amount of time for an Agile spike to take — it all depends on the project. That said, “timeboxing” is one of the key concepts behind the use of spikes in Agile.
Because Agile spikes are designed to break a problem down into smaller stories using research and testing, it can be tempting for a team to dive a little too deep into a solution, which may take time away from the rest of the roadmap.
Timeboxing Agile spikes helps product teams stay focused on the end goal and not spend too much time over-engineering solutions for a singular user story — no matter how important the feature may be.