The SPIKE Product Backlog Item

SPIKEs are not unusual and come up naturally during other SCRUM activities. This is happening for example, when something is blocking the progress of a sprint: the developer might face an issue that requires a more holistic approach on the design of the product, like for example how to do performance monitoring across all functions of the product; in this case, there is a need for a solution that will be applied consistently. Therefore, the topic is raised to the Scrum Master and Product Owner and it becomes clear that there is a need to invest some time in researching and designing a strategy for it.

For this a SPIKE backlog item is created by the Product Owner, with high priority, and developers are starting to work on it.

There are a few important things to remember about SPIKEs:

  • ·        They are for researching, learning, and discovery. Even if a prototype is created it's meant to be thrown away.
  • ·        The SPIKE is not meant to implement any completed work for the product increment. And as such, SPIKEs do not have user story points. This sets them an error to grief ratio as the time spent on the SPIKE during the sprint will not be spent finishing work and achieving velocity points.
  • ·        The SPIKE must have clear objectives and an outcome; questions to be asked, topics to be investigates, even concrete tasks to execute;
  • ·        Being exact on a SPIKE's objective and outcomes keeps the team from investigating related issues that might be fun but aren't relevant to the SPIKE's objective; 
  • ·        The SPIKE should be time-boxed so work does not drag on indefinitely. It could never take more than one sprint to complete. The team should have just enough time to get the knowledge required and put it to use to produce the outcomes in the SPIKE.

Some other indications that a team needs a SPIKE is if they're having trouble estimating a user story. It could mean that they need more information to understand the technical implications. SPIKEs can also be used to cleanup technical debt that's crept into the software. Some indication of technical debt is the team assigning very high user story points to something the product owners sees as simple. Or the team's velocity steadily decreasing over time as they try to work around the problem code. A team's velocity should increase overtime as the team learns to work together efficiently and honor their commitments. Additionally, the team could identify a problem area at the team's retrospective meeting and request a SPIKE to investigate or clean up the problem code.

The results from a SPIKE could determine the creation of additional entries in the Product backlog in order to implement the new design across all functions (including implemented ones) of the product. Might be that user stories with value for the stakeholders to be pushed back in order to do this. And this is why the Product Owner is involved and not just the Scrum Team (although it might very technical issues): as he has the vision of the product he is the only one to decide that this is something that should be implemented or not. And whatever is implemented in the Sprint is has to come, always, from the Product backlog.