We often think of “spikes” in bad terms, as seen in “spiking the punch” or the spike traps in Mega Man. But as it applies to scrum terminology, spikes can be useful in the right context. In an article for Scrum Alliance, Leonel Zapien Lopez explains what a spike is and the correct ways to use it.
A spike is a “technical” user story. It is inserted into a sprint and must be approved by a product owner like a regular user story, but it does not add any direct value like a normal user story. Instead, a spike is time used to gain knowledge in a technical area, which will eventually be applied toward designing/prototyping with new frameworks or technology. Thus, spikes reduce uncertainty and increase team understanding of foreign concepts.
Lopez believes that spikes must be estimated the same as any other user story, especially since the product owner has to approve them. He continues with this:
In this context, if a spike is a regular product backlog item (PBI), then it must be completed and demonstrated during the sprint demo (of course, it depends on the type of spike). Since a mock-up or prototype can be demonstrated, the team should be able to explain or show to the product owner what they have done and how it will help the team perform and accomplish a future story or feature. Sometimes a successful spike cannot be demonstrated by itself, but when a dependency to a regular user story is identified, by completing the related story then the spike is demonstrated indirectly. Either way, it has to be clear to the PO and to the whole team that the spike is done and that it supports the common goal.
Any work that is related to the spike should be taken on after the spike has been completed, since dependencies clearly exist.
You can view the original article here: https://www.scrumalliance.org/community/articles/2017/august/spikes-in-scrum-an-empirical-approach