SPIKE !

A very common type of user story that you see lying in your scrum or Kanban boards are SPIKEs! So what are they? And interestingly Why are they called as SPIKES?

  In agile software development, a spike is a story that cannot be estimated until a development team runs a time-boxed investigation . The output of a spike is an estimate for the original story .

Explanation :  Consider you want to implement a database related changes like introducing an extra column in a query or changing an already existing legacy stored procedure and you are not sure what all areas of your code will be impacted! Now this is a question which cannot be completely answered by business and need inputs from your team members who may not have worked on legacy code. At this point of time you use a SPIKE for figuring out the impacted areas of code due to your proposed changes.

Consider there is a proposed change related story like : Story ABC123: Change XYZ stored procedure to fetch JKL fields along with existing values.

Now you create a Spike for this saying STORY ABC124: SPIKE – Investigate the impacted code changes for implementing Story ABC123 

In this case team starts investigating the impacted areas and complexity of the efforts involved in implementing the proposed changes. They then can go back to Story ABC123 saying because of so and so complexity the efforts involved are 1,2,3 or 13 and may or may not be taken in this current sprint! 

Facts you don’t know about Spike :

1.      Ideally spike is not estimated as it is for investigation purpose, rather its time boxed. The max proposed time should not be more than 6 hours as if it takes more than that means we are impacting our current sprint capacity which we actually did not plan in sprint planning.

2.      Spike consume hours from your proposed sprint capacity which results in introducing spike in your burn down graph, hence are termed as spike!

3.      Spikes do not carry a business value or result in delivering a potentially shippable deliverable, rather they are enablers for other stories.

4.      As spikes do not carry any story points they don’t contribute to your velocity, so avoid more number of spikes in sprint if you don’t want to impact your velocity and burn down.

5.      Usually teams keep one design spike sprint itself for handling all spikes related to upcoming PI

So next time when your team wants to have a Spike, make sure you take care!