Much awaited discussion point’s are below on Spike v/s Stretch. We sometimes get confused to take story as a stretch or a Spike. Below written will explain you the clear difference between a Spike and a Stretch story.
Spike is an invention of Extreme Programming (XP), is a special type of story that is used to drive out risk and uncertainty in a user story or other project facet.
At the end of a sprint, the spike is done or not-done, just like any other story.
Spikes may be used for a number of reasons:
- The team may not have knowledge of a new domain, and spikes may be used for basic research to familiarize the team with a new technology or domain.
- The story may be too big to be estimated appropriately, and the team may use a spike to analyze the implied behavior, so they can split the story into estimable pieces.
- The story may contain significant technical risk, and the team may have to do some research or prototyping to gain confidence in a technological approach that will allow them to commit the user story to some future time box.
- The story may contain significant functional risk, in that while the intent of the story may be understood, it’s not clear how the system needs to interact with the user to achieve the benefit implied.
A stretch goal is a task or story that has been scheduled into a Sprint but that is not committed. It is considered a cherry on top, so a task that the Team hopes to get done in the sprint but isn’t absolutely sure they’ll get to.
Stretch stories are useful to help a Product Owner ensure that they have defined enough stories for the team to continue work uninterrupted during a iteration when things go well. That said, the designation of “stretch story” is only valid for the current iteration.
If the team does not complete a stretch story, that story simply becomes one of many stories available to the Product Owner to consider for inclusion in the next iteration. Since priorities can change, the Product Owner may or may not choose to include that story in the next iteration.