Spikes are an invention of Extreme Programming (XP), are a
special type of story that is used to drive out risk and uncertainty in a user
story or other project facet.
A story aimed at answering a question or gathering
information, rather than at producing a shippable product. Sometimes the
development team cannot estimate a story without doing some actual work to
resolve a technical question or a design problem. So we create a spike story
whose purpose is to provide the answer or solution. Like any other story, the
spike is then given an estimate and included in the sprint backlog and the
outcome demonstrated at the end of the iteration.
A spike story could include activities such as research, design,
exploration and prototyping. The purpose could be
1)To gain the knowledge necessary to reduce the risk of a
technical approach.
2)To get a better understanding of the requirement.
3)To increase the reliability of a story estimate for
technically or functionally complex features.
There can be two types of spike stories
1)Technical - To determine feasibility and impact of design
strategies.
2)Functional - To analyze the aggregate functional behavior
and to determine how to break it down, how it might be organized and where risk
and complexity exists, in turn influencing implementation decisions.
Since spikes do not directly deliver value to the user, they
should be used only rarely.
We should be able to
estimate (time box) it and the result (answer,
solution, prototype) should be something that can be demonstrated by the
development team and acceptable by the product owners.
It should be reserved
for more critical and larger unknowns only.
Do not plan the spike
story and implementation story in the same sprint. If you think it is that
simple then probably it is not a spike story since every story will inherently
have some unknowns discovered when implementing it.
