Many teams that take an “agile” approach to software development define requirements in the form of “user stories.” Not all the work a team performs lends itself to this form. It seems that people have come up with definitions of various “types” of stories other than “user” stories so that they can deal with work items that do not represent vertical slices of functionality that can be demonstrated to a business stakeholder. That’s fine as long as it’s practical and helps teams deliver effectively.
One of these non-story stories is the so-called “spike story.” I keep running into this in my team coaching work, so I did a quick Google search and found the term “spike story” is used pretty consistently. Definitions published by the ScrumAlliance, Agile Learning Labs, Scaled Agile Framework (SAFe), SolutionsIQ and others all refer to spikes as a type of “story.”
Answers to a question about spikes on Stack Overflow are more encouraging, as they mention spikes are time-limited and at least two of the respondents refrain from calling them “stories.” Even so, the notion that a spike is a kind of story seems to have become a widespread infection.
What I see in the field is that treating spikes as stories interferes with teams’ ability to keep their work flowing smoothly. I would prefer we stop referring to spikes as any kind of “story.”
As I see it, a “story” has certain characteristics:
- A discrete priority level set by the Product Owner or equivalent
- Some form of “value” to at least one stakeholder
- Some sort of functionality is delivered
- Testable acceptance criteria
- Non-determinate service time, so that the story is sized or estimated in some way during planning
I know that isn’t the canonical INVEST list. I know people can warp a “spike” so that it can be argued that it conforms to INVEST. That isn’t my point.
As I see it, a “spike” has certain characteristics, and they differ from those of a story:
- It is not prioritized by the Product Owner as part of the “what.” The need for a spike is determined by the team, as part of the “how.”
- It does not provide immediate or direct value to any stakeholder. It provides indirect value to the development team itself.
- It does not result in the delivery of any functionality.
- Its purpose is (a) to answer a question, or (b) to arrive at a better question.
- A fixed time-box is specified for the spike, so it is not sized or estimated.
These differences are significant enough that it makes sense to treat spikes quite differently from stories. Using the word “story” tends to cause confusion on the part of teams that are not very mature in agile thinking. I advise teams not to treat spikes as stories at all. This seems to help reduce friction and stress, reduce planning overhead, and improve flow.
I’ve observed that treating spikes as stories leads to a domino effect of suboptimal practices. First, teams spend an inordinate amount of time trying to estimate or size spikes, because the outcome of a spike is unclear. The very reason to do a spike is that we don’t have enough information to know or guess the size or duration of the work.
Second, teams aren’t sure when a spike “story” ends. There is no deliverable and no testable acceptance criteria, so the definition of “done” is very different from that of a proper story.
Third, treating spikes as stories skews the metrics – particularly Velocity and Cycle Time. That leads to low predictability in short-term planning for future iterations or cadences.
When teams treat spikes as time-bound experiments aimed at refining or answering a question, then these problems disappear. I’m not suggesting that we stop doing spikes; I’m suggesting that we stop calling them “stories,” because that word causes confusion for teams.
Anyone else have any observations on the subject?