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

—Albert Einstein


Spikes are a type of exploration Enabler story in SAFe. Originally defined in Extreme Programming (XP), spikes are used for such activities 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 overall behavior and determine:

  • How to break it down
  • How it might be organized
  • Where risk and complexity exist
  • How to use insights to influence implementation decisions

Technical spikes are used to determine feasibility and impact of design strategies.

Like other stories, spikes are estimated and then demonstrated at the end of the Iteration. Spikes also provide an agreed upon protocol and workflow that Agile Release Trains (ARTs) use to help determine the viability of upcoming Portfolio-, Value Stream–, and Program-Level Epics.


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. 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 that they can be split into smaller, quantifiable 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 and technical.

Functional spikes are used whenever there is significant uncertainty about how a user might interact with the system. They’re often best evaluated through some level of prototyping—whether through user interface mock-ups, hardware prototypes, wire frames, page flows, or other techniques to elicit feedback from the Customer or stakeholders.

Technical spikes are used to research various technical 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 implementation technologies that can be applied to a solution
  • Develop confidence about 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 both types of 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.

Quantifiable, 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 spikes generally produce information rather than working code. The spike should develop only the information needed to confidently identify and size the stories that drive it.

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 being made. When the acceptance criteria have been met, spikes are accepted by the Product Owner, as with any other story.

Timing of Spikes

Since a spike represents uncertainty in one or more potential stories, planning for both the spike and the resulting 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’s 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 risks. The goal of an Agile team is to learn how to embrace and effectively address this uncertainty in each iteration. Spike stories 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: 25 October, 2017