Adding Spikes to Gain Knowledge

Posted on August 28, 2015
by Doug Klugh

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.

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.

History

The 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.

Purpose

Examples of a spike may include root-causing a defect or testing the feasibility of an algorithm or a third party solution.  It may also be used to explore design alternatives for solving difficult problems.  If a spike requires more than minimal time and effort, it should be made visible by creating a story for it in the sprint backlog.  Since a spike does not result in development work, it should not be sized.  While team members usually want to get credit for working on a spike, it does not produce artifacts towards the development of the product.  It is simply a small amount of work to aid the team.  Team velocity should be aggregated from work delivered, not work expended.

Small & Valuable

A spike should be a small effort, with minimal impact on productivity.  Teams should not get in the habit of creating spikes to estimate work products.  Remember, estimates are just that… estimates.  They are not predictions.  In most cases, it is simply not worth a large effort to size a story or defect.  A team’s best guess is usually good enough.  Although if expert knowledge dictates that a defect could be of significant size, complexity, or risk, it may be worth creating a spike to root-cause such a defect if the origin is completely unknown.  Intrinsic knowledge should dictate if a spike is warranted.

Conclusion

Many projects will often require time to investigate solutions to tough problems or to root-cause origins of defects.  It is important to disclose substantial unknowns to stakeholders to facilitate identification of risks.  To enable visibility, a spike should be created as early in the release cycle as possible to help mitigate these risks.  Spikes should receive high priority and scheduled with other user stories in the next sprint.  Apply them sparingly and they will serve you well.