Spikes are a tool to explore options, even within the Delivery Horizon.

There are times where you just don’t know if a proposed solution will work or not. Or you need to do some research. Or you need to compare different options to see which performs best against the need, or within your environment. And honestly, the only way to find out is to try some things.

So a Spike is called to allow for this kind of exploration.

Spikes are used to time-box research, design, exploration, investigation, or prototyping activities in order to understand the effort required to deliver a backlog item or an initiative.

Agile Extension to the BABOK^®  Guide – section 7.16

Elements

When using Spikes, you need to define the spike goal and set the time box. Spikes are limited intentionally so that they don’t become an endless exploration.

There’s 3 types of Spikes

• Functional – These explore options to break down the item to identify risks
• Technical – look at design impacts and feasibility
• Exploratory – looks at the organization as a whole to show organizational risks.

So, Spikes technically can occur in all three horizons.

Description

In our description of Spikes, it’s important to remember this should be an infrequent technique, used when an item or initiative needs more information. Spikes are a kind of prototype.

Again they are time-boxed, have a clear objective and outcome, and can address Functional, Technical and Exploratory elements.

They operate in the context of Requirements Management and the audience is the Internal Team.

Usage Considerations

Spikes help gain clarity and focus, as well as permission to experiment and gain knowledge. They’re great for proof of concepts.

Some issues are if the time box is not an appropriate size.

I’ve alluded to not using Spikes too often. The reason isn’t just because of creep. It also is because too many spikes can indicate that the backlog is not refined well enough.

• Agile
• BA Techniques