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.