Agile 101

Project Management, Digital Publishing and Agile Software Development

Using ‘Spikes’ in Agile Software Development

Posted by Tara Hamilton-Whitaker on September 29, 2009

‘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 Agile101 RSS to be notified when I upload new Articles, Videos, Templates and Tips!

Advertisements

2 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!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

 
%d bloggers like this: