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

—Albert Einstein

Spikes


Note: This article is part of Extended SAFe Guidance and represents official SAFe content that cannot be accessed directly from the Big Picture.


Spikes are a type of SAFe Enabler Story. Defined initially in Extreme Programming (XP), spikes represent activities such as exploration, architecture, infrastructure, research, design, and prototyping. Their purpose 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.

Like other stories, spikes are estimated, implemented and demonstrated. They also provide a mechanism and workflow that Agile Release Trains (ARTs) use to help determine the viability of Epics.

Details

Agile and Lean value facts over speculation. When faced with a question, risk, or uncertainty, Agile Teams conduct small experiments before moving to implementation rather than speculate about the outcome or jump to a Solution. Teams may use spikes in a variety of situations:

  • Estimate new Features and Capabilities to analyze the implied behavior, providing insight into the approach for splitting them into smaller, quantifiable pieces
  • Perform feasibility analysis and other activities that help determine the viability of Epics
  • Conduct primary research to familiarize them with a new technology or domain
  • Gain confidence in a technical or functional approach, reducing risk and uncertainty

Spikes may involve creating a small program, research activity, or test demonstrating new functionality.

Technical and Functional Spikes

Spikes primarily come in two forms: technical and functional.

Functional spikes – They are used to analyze overall solution behavior and determine the following:

  • How to break down and organize work
  • Where risk and complexity exist
  • How to use insights to influence implementation decisions

Technical spikes – They are used to research various approaches in the solution domain. For example:

  • Determine a build-versus-buy decision
  • Evaluate the potential performance or load impact of a new user story
  • Evaluate specific technical implementation approaches
  • Develop confidence about the desired solution path

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 to quickly understand my past, current, and projected energy consumption.”

In this case, a team might create both types of spikes:

  • A technical spike – to 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
  • A 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, use them sparingly. However, they do create knowledge and learning. The following suggested guidelines apply.

Quantifiable, Demonstrable, and Acceptable

Like other stories, spikes are put in the Team Backlog, estimated, and sized to fit in an iteration. Spike results may differ from a story because they often produce information rather than working code. They should develop only the information required to identify and size the stories that drive it confidently or to determine the best technical approach.

The output of a spike is demonstrable, both to the team and to any other stakeholders, which brings visibility to the research and architectural efforts and helps build collective ownership and shared responsibility for decision-making. The Product Owner accepts spikes that have been demoed and meets its acceptance criteria.

Timing of Spikes

Since they represent uncertainty in one or more potential stories, planning for both the spike and the resulting stories in the same iteration is sometimes risky. However, if it’s small and straightforward, and a quick solution is likely to be found, doing both in the same iteration can be efficient.

The Exception, Not the Rule

Every user story has uncertainty and risk. That’s the nature of Agile development. The team discovers the right solution through discussion, collaboration, experimentation, and negotiation. Every user story contains spike-like activities to identify the technical and functional risks. The goal of an Agile Team is to learn how to address uncertainty in each iteration. Spikes are critical when high uncertainty exists or there are many unknowns.

 


Learn More

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

 

Last update: 13 March 2023