Spikes are for research

Spikes are for research

A spike is a type of user story that is used to answer a question, gather information, perform a specific piece of basic research, address project risks or break a large story down. Fundamentally, spikes are used to address uncertainty by gathering specific information to understand a functional or technical requirement. For example, when the team needs to prove a specific technical problem or do not have enough information to estimate the story they would use a spike.

Spikes are treated like user stories using the standard format (persona, goal, benefit).  The benefit is the goal of the research, rather than direct user value.  Because a spike does not deliver direct value they should be used sparingly. Spikes are not a cop-out to slip back into waterfall behavior.  Another difference between a spike and a typical user story is that are not estimated, but rather time-boxed.  Instead of an estimate, the team commits to spending a specific quantity of time performing the necessary research.  Upon the completion of the time box the original story is reframed, groomed, split or rewritten based on the information learned during the time box.

Spikes should be estimable, demonstrable and acceptable. They should be added to the project backlog and prioritized.  The time box needs to be long enough to answer the question posed in the spike. Once accepted into the sprint the team effort required for the spikes time box should be burned down just like another story.  At the end of the sprint the results need to be demonstrated during the sprint demo. As with all stories the outcome of a demo is that the spike results are accepted or rejected.  Spikes almost always generate new stories.

Teams need to have a mechanism for dealing with what they don’t know. But, don’t get addicted to spikes.  If every story needs a spike, the wrong team is probably working on the project.  Spikes are a serious tool for teams to gain knowledge, determine how to mitigate a risk, validate that a technical approach is feasible or to decide how to estimate a story.  Spikes are not a back door to analysis, design, build and test (i.e waterfall).