Spikes are a sort of user story invented by Extreme Programming (XP) that is used to gather the knowledge needed to lower the risk of a technological approach, better comprehend a demand, or improve the accuracy of a narrative estimate. The sprint in which a spike is contained has a maximum time-box size. The spike will be determined as done or not-done at the conclusion of a sprint, just like any other user story. A Spike is an excellent technique to manage risks early on by allowing the team to gather input and have a better grasp of the complexity of an upcoming PBI.
When Should You Use Spike?
Due to potential blockages, the crew is sometimes unsure if they can finish the story and can't even estimate it. As a result, you may think of a spike as an investment in a Product Owner's ability to figure out what needs to be built and how the team will do it. The Product Owner allots a small portion of the team's capacity now, ahead of when the story is due, so that the team understands what to do when the narrative arrives in the sprint.
Spikes can be utilised in the following situations:
The crew may be unfamiliar with a new technology, and spikes may be employed for preliminary study to establish the new technology's viability (domain or new approach).
A tale must be implemented with the help of a third-party library with a badly defined and documented API.
The story may have a high level of technical risk, and the team may need to conduct some tests or prototypes to establish confidence in a technology approach that will allow them to commit the user story to a future deadline.
