Nailing the Spike

The misguided development of "spikes" by agile teams is a major impediment I have observed on teams I have joined. The use of spikes can be problematic for several reasons that I discuss in this post, because spike stories have unique constraints and attributes that distinguish them from user stories, system stories and defect stories.

The Defining Character of a Spike Story

A spike has a unique semantic characteristic: it is an activity that yields knowledge or a decision. A spike does not provide product functionality, but should enable the development of product functionality. The knowledge obtained from a spike should reduce or eliminate uncertainty the team perceives in a 'regular' story, but not just any uncertainty.

Justification to Do a Spike

Every story has some amount of 'normal' uncertainty, and the team should address this normal uncertainty during the story's implementation within the sprint. A spike may be justified only if a story has 'extreme' uncertainty such as "We have no idea at all how to solve this." When a regular system story or user story has this extreme uncertainty, it clearly cannot be reliably estimated until the uncertainty is reduced or eliminated. So, if a story has been estimated and then the team spins off a spike story, they are approaching this process backwards. Breaking off a spike is most useful when the original story, or feature, has so much uncertainty that it would be imprudent to even estimate that story until its uncertainty has been reduced through new, specific knowledge.

Is a Spike a Story?

There are discussions--sometimes heated--that a spike effort is not a story. I do not engage in this battle. A spike requires investment of time and energy, it yields a definable value in knowledge obtained, and has acceptance criteria that define the knowledge goal of the spike. All of these are attributes of a story. For these fundamental reasons, all major authors in the agile community describe spike efforts as stories.

A Spike for Upfront Work

The single most frequent perversion of a spike story is to perform work that properly should be part of a user story or system story. This segregation to do up-front 'preparation' is a symptom of a mindset that regards a spike as a representation of a Waterfall phase such as Requirements Gathering, Analysis, or Design. This is very wrong. Agile teams must accept that a story's elaboration through Analysis, Design, Coding, and Testing is all part of the story development within a single sprint.

Assign Time, not Story Points

A unique attribute of a spike story is that it is not given a story point estimate. This makes perfect sense: the spike does not deliver product value, it is a knowledge enabler of product value. If a spike story is estimated in story points these points would be included in the team's velocity. But velocity is the rate at which accepted product functionality is delivered, and spikes do not deliver product functionality—they enable the delivery of product functionality.

Spike stories are given a time-duration for the execution of the spike effort. This time-duration can be a few hours, or it can be an entire sprint, but at the end of the allotted time the spike story is reevaluated by the team to determine if the spike story's acceptance criteria have been satisfied, if the spike should be abandoned, or if the spike needs to be extended.

Closure Must Be in the Description

Invariably, immature teams create spike descriptions containing verbs such as 'research' or 'evaluate.' But these verbs have no closure. How do you know when 'research' is done? What criteria satisfy a goal of 'evaluate'?

A spike description must contain a definition of its own closure. Consider this example of two spike stories:

• As a developer I want to research user interface framework libraries…
• As a developer I want to evaluate NoSQL database interface offerings…

There is no information in these descriptions of how I know when I am done. Now consider these revisions:

• As a developer I want to prove XYZ UI framework is backward-compatible with our older version of Angular.
• As a developer I want to demonstrate that we can convert and run our three most frequent SQL queries using MySQL's NoSQL API.

This example illustrates a huge difference in precision and knowing when we have achieved closure on a spike.

Spikes should be Rare

Spikes are unique and limited in purpose, and invoking a spike story should be relatively rare. A frequent and proper use of a spike story is to obtain information to make a build vs. buy decision. However, all spike stories should yield knowledge to enable product delivery. If a team cannot formulate a specific question to be answered or decision to be reached, a spike is not the right artifact to embrace.

I love working with teams and executives to find effective solutions. Email me at gary@effectivescrummaster.com and let's explore how we might partner on your challenges.