Put a Spike in It

Spikes are part of agile.

People outside of the software business think technology is magical.  People compare developers to magical elves from the fairy tale "The Cobbler and the Elves." At the drop of a pin, developers can create solutions and generate mounds of money from their efforts.  The reality is different.  Software development requires smarts, but it also includes constant pressure to meet deadlines and frustration as you try to solve problems.  It is not magic. Instead, it is grinding work.  The most misunderstood part of that work is the prototyping, research, and analysis necessary to create working software.  In agile, we call this work a "spike," and we will discuss it today on the blog. 

When you first learn agile, you realize the product owner writes user stories, and the stories reside in the product backlog.  The team then pulls those stories into a sprint, and work gets accomplished.  When we look at that work, it typically falls into two main categories: user stories and bugs.  A user story covers improvements or new functionality.  A bug or defect covers broken behavior in the application.  These two types of product backlog items make up most of the work done by the team.  The approach worked well for the construction and maintenance of a project but was insufficient for research and development. 

The realization that analysis and research are not adequately captured in the product backlog led to the spike's creation.  A spike is a special kind of user story in agile.  It represents proof of concepts and research.  The output of a spike is more user stories that contribute to sprint goals. 

Here is an example of a spike:

[Spike] Research PDF creation from License form

As a developer, I want to understand how to create a PDF file once a customer saves a license file because this is an upcoming requirement. 

-Use a third-party tool to create PDF's

-Then, save PDF as an attachment and email it to the customer.

This is a spike!  The outcome should be a proof of concept and more user stories.

As you can see, a spike looks similar to a user story.  The only difference is the acceptance criteria are vaguer to make it possible to conduct research.  It is also clear some tangible learning must result from the work.  The person assigned the spike should do the research and then help the product owner write the other user stories to meet a future sprint goal.

During the daily scrum, the team reports on what it is working on and what they are learning.  The spike also explains why the group may be working on fewer story points than usual because the research is taking up the team's mental bandwidth.  Thus, the three main items in a backlog should consist of stories, bugs, and spikes. 

A spike helps the team track research and development.  Using spikes allows the team to explain slow-downs in work.  Finally, a spike enables the team to prepare for future work without blundering into a mistake.  Spikes are a helpful tool in your agile toolkit; give them a try and see what you can accomplish.

Until next time.