Posted on August 28, 2015
Planning an Agile project can be rather simple when all is known.
When the market is predictable, requirements are clear, the technology is well understood, and the team is experienced in using all of the required tools, there isn’t much research required to complete a project.
But for those times when all of the stars are not aligned and (God forbid) there is something the team does not fully understand, the team will need to dedicate some time to investigation or experimentation in order to complete the project.
In terms of Agile and Extreme Programming (XP), this effort is known as a Spike.
by Doug Klugh
What is a Spike?A spike is a time-boxed period designated to reduce uncertainty by learning enough about a feature, technology, or process to better estimate, develop, or fix an upcoming feature or defect. It is used to understand how to best implement a requirement or propose a solution to help the customer make sound product decisions. All artifacts resulting from a spike are to be thrown away; the only thing to be retained is knowledge. The goal is to spend as little time and effort as possible to reduce risk by learning just enough to proceed in estimating and developing the work product. You should not be spending enough time to build a viable solution, just enough time to run a quick and dirty experiment to answer a question.
HistoryThe term "Spike" comes from an analogy to rock climbing. Climbers will often stop to drive spikes into the rock face to secure their ropes. While this does not move the climbers towards the top of the mountain, it does enable future climbing.
Similarly, a spike in eXtreme Programming does not produce production code, but it does enable future story development. For this reason, spikes are not assigned story points because they do not directly contribute to the team's velocity. By itself, a spike does not deliver value to the customer.