What is a Story Spike
Spikes are a type of exploration Enabler Story. 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. 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.
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 about the approach for splitting them into smaller, quantifiable pieces
Perform feasibility analysis and other activities that help determine the viability of epics
Conduct basic research to familiarize them with a new technology or domain
Gain confidence in a technical or functional approach, reducing risk and uncertainty
Spikes involve creating a small program, research activity, or test that demonstrates some aspect of 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:
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 – 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 so that I can 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. 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 typically produce information rather than working code. They should develop only the necessary data to identify and size the stories that drive it confidently.
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 also helps build collective ownership and shared responsibility for decision-making. The Product Owner accepts spikes that have been demoed and meet 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, then it can be quite efficient to do both 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 address uncertainty in each iteration. Spikes are critical when high uncertainty exist, or there are many unknowns.
There are two other characteristics that spikes should have:
Have clear objectives and outcomes for the spike. Be clear on the knowledge you are trying to gain and the problem(s) you are trying to address. It's easy for a team to stray off into something interesting and related, but not relevant.
Be timeboxed. Spikes should be timeboxed so you do just enough work that's just good enough to get the value required.
Indications a spike may be needed
It may not always be obvious that you need to take on a spike. Here are some indications that your project team could benefit from spike work:
Trouble estimating
Your team is having trouble estimating stories effectively. Lots of dissension and differing opinions on how big certain stories are. This can lead to . . .
High point estimates
Your story point estimates are very high for what the product owner sees as easy items. The team sees much more work than is immediately apparent. This could be an indication that there's technical debt or something that the team is working around to try to deliver stories.
Patterns of difficulty
Stories from specific areas of the application are consistently late or difficult for the team to complete.
There are lots of bugs and QA items from certain types of stories.
There's a pattern of feedback from retrospectives in which the team refers to difficulty with a technology or implementation used.
The team speaks out
Your team flat-out tells you that there's a problem and it has to be fixed or else.
More subtly, the team seems worried about creeping technical issues. You may start hearing rumblings during planning or retrospective meetings. Is the platform scaled well enough?
Scrum teams are supposed to be self-driven. Sometimes they need empowerment and guidance with spikes. They may feel guilt taking time away from market-facing features to work on something that may never be delivered. The product owner may indirectly discourage this type of work. You, as the Scrum Master, need to empower them to declare what needs to be done and assist them in advocating for this work with the product owner.
Where to find the spikes
Has the team already told you what needs attention? Are there backlog items that are labeled with technical debt? Many teams will express what needs to be done.
Are there backlog items that keep getting pushed to the bottom by the product owner because he or she doesn't understand their value?
What are your team's pain points? Do they have the same problems sprint after sprint in completing stories or certain types of stories?
Is your software deployment process difficult? If so, where is it in need of attention?
After you've gone through this exercise, you'll probably find several candidates for spike work. Unless you stop the presses, you can't do them all at once. To help the product owner find the nuggets, I do an exercise with the team to determine the effort-to-grief ratio.
Items causing the most grief to the team should be looked at as top candidates. Host a session with the team to get them to express issues that are causing grief. Have them rank the items on a scale of 1 to 5 (1=low pain, 5 = high pain). Finally, get the team to size the effort to work on a spike that can help them learn or understand how to solve the problem. Then lay out those items in a table similar to the one shown below:
Looking at the items this way will make it immediately clear which spike candidates are the best choices for inclusion in your upcoming sprints.
You may notice that the effort/point scale does not show stories in the 1-point range. Small issues causing your team pain should be quickly researched and handled without question. Product owners should not protest small research items, and your team should be empowered to handle them on their own during sprints.
Spikes can be very useful during the life of your project. They can be especially useful early on, when your team is still getting comfortable with the technology and with each other. Teams need a way to determine how to come up with proper stories and solutions for the project where the tool or technology is not well known. They give your team permission to spend time on value-driven research. They're a good tool to have in your arsenal to find out if something is possible or not.
Reference Materials