Using ‘Spikes’ in Agile Software Development


feature photo

‘Spikes’ are time boxed periods of research and development used in Agile Software Development environments to research a concept and/or create a simple prototype.

Spikes will usually take place in between sprints and are often introduced before the delivery of large Epics or User Stories in order to:

  • Secure budget
  • Expand knowledge
  • Proof of concept

The duration and objective(s) of a Spike will be agreed between the Product Owner, Product Manager and Delivery Team before the start.  They will normally be shorter than a standard sprint, however can range in duration from a few hours to a few days long or more. 

It is important to keep focused and during a Spike – ultimately, we want to get back to delivering tangible value as soon as possible!

Unlike Sprint commitments, Spikes may or may not deliver tangible, shippable, valuable functionality.  For example, the objective of a Spike might be to successfully reach a decision on a course of action.

With that said, a prototype created during a Spike may sometimes evolve into the final product or may be used verbatim in a future release.

For larger teams, a Spike might be accepted as one of many sprint delivery objectives

You might choose to do this in any or all of the following circumstances:

  • A multi-team environment with synchronised sprints
  • Only a few members of a sprint team can/should focus on delivering the Spike

One may ask how you reflect the delivery of a time boxed piece of effort alongside user stories on a burndown chart.

You have two options:

  • Do not include the spike in your burndown chart
  • Burn down in hours

If you traditionally burn down in story points, you should probably omit the Spike from your burn down.

You should still discuss the findings at the Sprint Review and the success of the sprint will still depend on the successful delivery of the pre-agreed Spike objective alongside other Sprint objectives.

If you burn down in hours, then burn down on time elapsed as opposed to the perceived number of hours required to deliver the objective.

Remember, Spikes are time boxed – the Spike is over when the time is up, not necessarily when the objective has been delivered.


Subscribe to the to be notified when I upload new Articles, Videos, Templates and Tips!

Share this!
  • Print
  • PDF
  • del.icio.us
  • Digg
  • DZone
  • Reddit
  • Technorati
  • StumbleUpon

3 Responses to “Using ‘Spikes’ in Agile Software Development”

  1. [...] This post was mentioned on Twitter by Naresh Khalasi. Naresh Khalasi said: Spikes in Agile Development – http://bit.ly/BbXIz [...]

  2. Nice post, interesting approach to agile software development!

  3. [...] they reach some new grounds where the future direction can not be seen or predicted they perform spikes, sending out one person (“go and see”) in each direction of interest to look a couple [...]