Spikes – The Value of Information Gathering

User Stories have become the defacto standard in agile development to convey business needs to agile development teams.  There are countless posts and informative books and articles on how to write great user stories, but the essential statement of what a user story encompasses is to provide a short snippet of information that stimulates a conversation about adding value to the product.  Good user stories employ other attributes, such as valid acceptance criteria and following guidelines such as INVEST (Independent – Negotiable – Valuable – Estimatable – Small – Testable).

However, there is another type of story that is very useful: the Spike story.  A spike story is essentially a learning opportunity that we have discovered and want to explore.  The main difference between a spike and a user story is that where a user story adds value, a spike story answers a question.  Spikes allow us to do valuable work without necessarily adding direct (immediate) value to the product.  Spikes give us the ability to do research and knowledge gathering while including the needed constraints that a story framework provides. 

When to use Spikes?

Spikes are very useful in situations like the following:

Scenario I:  A user story has a well-defined business value, but we are unsure how to approach it.  For example, the user story calls for a particular grid capability on the user screen, but the team is unsure what the best technology is to accomplish this, and the outcome will influence the product owners view of the feature.  The team can create a spike story to create a working prototype for the PO to review to help define the feature and its acceptance criteria.  We can provide knowledge to the PO to help her/him see what is possible in creating business value, to be able to answer questions like “Is it realistic to have acceptance criteria that requires the ability to mix different data elements? “

Scenario 2:  The story is too complex, and we can’t find a way to break it into smaller business value chunks.  Can we solve some of the technical issues behind the story to reduce the complexity?  Can we do research on possible solutions to help reduce some of the uncertainty?  Let’s take our grid example from above, but what if the complexity comes from unknowns on how the new grid will perform with the current database technology.  Perhaps we can do a Spike on how the grid can consume the data in a performant way?

Scenario 3:  What if the PO has specified some business value, but the team has no clear idea on how to implement it?  This is another good usage of a spike, and can use techniques like A/B testing or beta tester feedback loops to determine the best way to move forward.  The team can use information from the PO on the vision of the feature, and experiment with different options to help further define that vision.

Keep it focused on value

One caution on using spikes: do not abandon the guidelines and constraints we apply to user stories.   Just because we are gathering information does not mean we can toss out the focus on business value.  Make sure that spikes still have a good title and description that define the conversation to take place.  Ensure that you are using the proper voicing in the story so that you maintain focus on who will be helped by this information.  Hint: it is common and acceptable to use the PO or team as the role needing the information, but avoid a specific role on the team, such as developer.  The entire team should be able to consume and learn from the knowledge gained.  Above all, make sure that you define and agree upon what “done” looks like in the form of good acceptance criteria.

By Example

Going back to our grid example, let’s see what a spike story might look like. 

Business Value: Give the user the best experience when merging their media files in their library.

Spike Story: As a product owner I want to learn about different ways to allow the user to merge media files in their library.

Acceptance Criteria: Verify I can review 2-3 options for merging the data.  Ensure that I can accurately compare the pros and cons between the different options. 

Note that the acceptance criteria does not specify being able to actually merge the data, since we are not trying to solve the user story, only the spike.  The important part is that we provide the knowledge in a consumable format.

Quest for Knowledge

One of my favorite facets of agile development is the importance of acquiring knowledge, and applying it to reach our goals.  This is evident in the agreement with our stakeholders to invest in this knowledge acquisition.  Spikes are the contracts we use to justify these explorations and discoveries. 
Donald Reinertsen discussed in his excellent book "The Principles of Product Development Flow" the principle of buying information.  "Information reduces uncertainty.  When we reduce the uncertainty of an economic outcome, we create economic value."  Columbus and crew went looking for a short cut to Asian spices (perceived economic value), but came back with the (re)discovery of a new world (unexpected, but far greater economic benefit).  Sometimes those investments return value we never saw coming.