In today's Agile development environment it is not uncommon for teams to create special User Stories called Spikes. Spikes are used to gain the necessary knowledge needed to do the requested work and to reduce risk and uncertainty. The term Spike was originally coined in Extreme Programming (XP) by Kent Black.
At Above Property, it is not uncommon for us to use a Spike story when we are exploring a new technology or determining the direction for a new business process.
Spike Stories are subject to the same rules of any other story. They have a short, simple description from the perspective of the person desiring the functionality and explicit acceptance criteria. They are pointed and placed into the iteration just like any other story.
For us, the result of a Spike story is usually a well-written and pointed User Story or a series of User Stories. Once the Spike has been placed in an iteration, we attack it just like any other Story.
While there are valid times and places to use Spikes, be careful. Using a Spike inappropriately can hinder your team’s ability to work on the right tasks at the right time.
I have observed that new and immature adopters to Agile will sometimes create an excessive number of Spike stories. Resist this temptation and embrace the agility that the methodology provides. If your team needs everything lined up before they commit, then invest in some coaching and help them along. A zealous and active Product Owner that grooms the backlog can greatly reduce the number of Spike Stories.
Here’s a list of when NOT to use a Spike:
- to clarify minor details
- as a crutch because there is still some ambiguity in how you will do the work
- for something you could figure out with a couple of quick discussions and a white board
Posted via OnFast - http://www.OnFast.com