guidance-icon

If we knew what we were doing, it wouldn’t be called research.
 
—Albert Einstein

Spikes Abstract

Spikes are a special type of Enabler story in SAFe. Originally defined within XP, spikes are used for activities such as research, design, investigation, exploration, and prototyping. The purpose of a spike is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a Story estimate.

Spikes primarily come in two forms: technical and functional. Functional spikes are used to analyze aggregate functional behavior and determine how to break it down, how it might be organized, and where risk and complexity exist, in turn influencing implementation decisions. Technical spikes are used to determine feasibility and impact of design strategies.

Like other stories, spikes are estimated and are demonstrated at the end of the Iteration. Spikes also provide an agreed protocol and work flow that Agile Release Trains use to help establish viability of upcoming Portfolio, Value Stream, and Program Epics.

Details

Agile and Lean value facts over speculation. When faced with a question, risk, or uncertainty, rather than speculating about the outcome or jumping to a Solution, Agile Teams conduct small experiments before moving to implementation. Originally defined in XP, Spikes are a specific type of Enabler story in SAFe. Teams may use spikes in a variety of situations:

  • Estimate upcoming Features and Capabilities to analyze the implied behavior, so they can be split into smaller, estimable pieces
  • Perform feasibility analysis and other activities that help determine the viability of Epics
  • Conduct basic research to familiarize themselves with a new technology or domain
  • Gain confidence in a technical or functional approach to reduce risk and uncertainty

Spikes generally involve creating a small program, research activity, or test that demonstrates some aspect of an upcoming feature.

Technical and Functional Spikes

Generally, there are two types of spikes: functional spikes and technical spikes.

  • Functional spikes are used whenever there is significant uncertainty as to how a user might interact with the system. Functional spikes are often best evaluated through some level of prototyping, whether it be user interface mock-ups, hardware prototypes, wire frames, page flows, or other techniques suited to elicit feedback from the Customer or stakeholders.
  • Technical spikes are used to research various technical approaches in the solution domain. For example, a technical spike may be used to determine a build-versus-buy decision, to evaluate the potential performance or load impact of a new user Story, to evaluate specific implementation technologies that can be applied to a solution, or for any reason when the team needs to develop a more confident understanding of a desired approach.

Some features and user stories may require both types of spikes. Here’s an example:

As a consumer, I want to see my daily energy use in a histogram so that I can quickly understand my past, current, and projected energy consumption.

In this case, a team might create two spikes:

  • Technical spike: Research how long it takes to update a Customer display to current usage, determining communication requirements, bandwidth, and whether to push or pull the data
  • Functional spike: Prototype a histogram in the web portal and get some user feedback on presentation size, style, and charting

Guidelines for Spikes

Since spikes do not directly deliver user value, they should be used sparingly. The following guidelines apply:

Estimable, Demonstrable, and Acceptable

Like other stories, spikes are put in the Team Backlog, estimated, and sized to fit in an Iteration. Spike results are different from a story, because they generally produce information rather than working code. The spike should develop just the information sufficient to resolve the uncertainty in being able to identify and size the stories that drive the spike.

The output of a spike is demonstrable, both to the team and to any other stakeholders. This brings visibility to the research and architectural efforts and also helps build collective ownership and shared responsibility for the key decisions that are being taken. And, like any other story, spikes are accepted by the Product Owner when the acceptance criteria has been met.

Timing of Spikes

Since a spike represents uncertainty in one or more potential stories, planning for both the spike and the resultant stories in the same iteration is risky. However, if the spike is small and straightforward and a quick solution is likely to be found, then it can be quite efficient to do the spike and complete the stories in the same iteration.

The Exception, Not the Rule

Every user story has uncertainty and risk—that is the nature of Agile development. The team discovers the right solution through discussion, collaboration, experimentation, and negotiation. Thus, in one sense, every user story contains spike-like activities to identify the technical and functional risk. The goal of an Agile Team is to learn how to embrace and effectively address this uncertainty in each iteration. A spike story should be reserved for the more critical and larger unknowns.


Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison Wesley, 2011.

Last update 4 October, 2015