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. Defined initially in Extreme Programming (XP), they represent activities such as research, design, investigation, exploration, 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.
The Agile and Lean approaches 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 used to split them into smaller, quantifiable pieces
Perform feasibility analysis and other activities that help determine the viability of epics
Conduct basic research to familiarize the team with a new technology or domain
Gain confidence in a technical or functional approach, thereby reducing risk and uncertainty
Spikes involve creating a small program, research activity, or test that demonstrates some aspect of new functionality.
Like other stories, spikes are estimated and then demonstrated at the end of the Iteration. They also provide an agreed-upon protocol and workflow that Agile Release Trains (ARTs) use to help determine the viability of Epics. Spikes primarily come in two forms: technical and functional.
Functional spikes are used to analyze overall solution behavior and determine:
How to break it down
How to organize the work
Where risk and complexity exist
How to use insights to influence implementation decisions
Technical spikes 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 in 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 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.
Since spikes do not directly deliver user value, use them sparingly. The following guidelines apply.
Like other stories, spikes are put in the Team Backlog, estimated, and sized to fit in an iteration. Spike results differ from a story in that spikes typically produce information rather than working code. They should develop only the data necessary to identify and size the stories that drive the results confidently.
The output of a spike is demonstrable, both to the team and to any other stakeholders. It shines a light into 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 meet its acceptance criteria.
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 the effort is small and straightforward, and if a quick solution is likely to be found, then it can be quite efficient to do both in the same iteration.
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 address the uncertainty inherent in each iteration. Spikes are critical when high uncertainty exists and when there are many unknowns.
LEARN MORE
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison Wesley, 2011.