Spike

A task aimed at answering a question or gathering information, rather than at producing shippable product. Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a “spike,” which is some work whose purpose is to provide the answer or solution.

Etymology

The term spike comes from Extreme Programming (XP), where “A spike solution is a very simple program to explore potential solutions.” XP guru Ward Cunningham describes how the term was coined on the C2.com wiki: “I would often ask Kent [Beck], ‘What is the simplest thing we can program that will convince us we are on the right track?’ Such stepping outside the difficulties at hand often led us to simpler and more compelling solutions. Kent dubbed this a Spike. I found the practice particularly useful while maintaining large frameworks.”

46 Responses to Spike

We “point” spikes and include them in our team velocity. This helps us be realistic about iteration capacity. My concern is that the spikes that occur after the first few iterations of a release are seldom anticipated and are not included in initial release planning. This means our claimed velocity is distorted when it is applied to release planning. (Spike points seldom equate directly to initial MMFs) What is the best way to estimate and incorporate spikes? I can, of course, point spikes for iteration capacity planning but then not include them in velocity calculations, but, silly as this may sound, I think that will discourage my teams from accepting spikes. They seem to like consistent velocities. And unpointed timeboxing is likely to have the same result.

The “etymology” here is basically a non-etymology. It does nothing to explain the origin of the term “spike”. I understand the concept of the effort so named, but want to know where the word came from. “Kent dubbed it a ‘spike’” says nothing. *Why* did he dub it a “spike” as opposed to an “auger” or a “spear” or a “fruit salad”??? I have issue with this as many programmers I work with hear the term and chuckle (in a bad way… as do I).

My recollection from the early XP Universe conferences in 2001/2002, is that the term “spike” comes from an analogy to rock climbing. When climbing, we might stop to drive a spike into the rock face. Driving the spike is not actual climbing — it does not move us closer to the top — but rather it enables future climbing.

Similarly, a spike in XP does not produce production code — it does not develop an actual story in the backlog — but rather it enables future story development. I was taught in the XP Immersion workshop (given by Robert Martin, Ron Jeffries & Kent Beck in 2000), that spikes are not given story point estimates because they do not contribute to forward velocity on completing the backlog — they are in essence, research overhead and absorbed into the team’s ongoing story velocity. XP was never as obsessed with “precision” in release planning as Scrum has become.

It would be interesting to ask someone like Ron Jeffries, who was no doubt very close to the creation of the spike concept, where the inspiration for the term really came from.

Like Paul, I was taught or just imagined that the spike refers to a rock-climber’s spike. However, leaving the idea that it does not actually get us forward, I have often thought that it MAY help them team move forward, much like spiked tires on icy roads.
There is the chance that it is throw-away work/code…much like the rock-climbers spike, if it only demonstrates what doesn’t work. But, if the prototype, or mock up is successful, or leads the team to direct learning, then we’ve made traction and have forward progress. So, it like studded or spike tires to the team and throws us forward. -Just a concept to consider to help the team visualize the ‘why’ behind the term.

We’ve never used Spikes on our team. If Spikes are research, or trial-and-error, we simply create a Research task. And, by nature of trial-and-error, it’s possible that a “Spike” task could lead nowhere. So, to me, it would be overkill– and perhaps improper– to point out Spikes. If a task needs research time, we add that to the task at hand.

My analogy was since we do not point Spikes, so it might caused an impact on velocity. And sudden dip in velocity trend on sprint versus velocity might create spike on the graph.
Climbing making sense atleast not linked with metrics .☺️

I was co-training a CSM class with Chet Hendrickson just yesterday, and the question of etymology of ‘Spike’ came up. Chet was there when it was named ‘Spike’, and he said it was actually named after the really long nails that hold a gutter on to your house. Still not sure if Chet was pulling my leg. Also, he worked Ward Cunningham into the naming of ‘Spike’.

As I write this, I’m wondering when I turned into the old guy who says “Yeah, we did that all 20 years ago!”, but…
The term spike predates Agile and XP. The idea, IIRC, was that rather than designing/developing top-down or bottom-up, you started with a narrow “spike” that went all the way from UI (if appropriate) to low-level, in order to mitigate risk, and act as a proof of concept. So, essentially the same purpose as used for later. I’m trying to find a reference, but of course the Google hits are now all for agile

+1
Yes. For example sending a String end to end from the user to the backend server. That would validate that they were not missing or unconsidered pieces and lower the risk of the “horizontal” work of making the system work for all data types and use cases.
I am doing one now!
We have dozens of AI features recognizing distracted driving, but I am doing a spike to determine if we can send a boolean end to end when the user hits a button on the device.
So spikes also help to avoid blocking exercising all elements of a system, when part of product functionality takes longer to develop than others.

Funny, we used to simply call this type of activity “research” or “prototyping” or “risk analysis”. Very much like the self appointed “gang of four” and their “design patterns” some of this agile terminology obfuscates or creates vagueness of purpose. It’s really okay to use multisyllabic words or complete phrases to describe something to make the goal completely clear.

“… Like any other story or task, the spike is then given an estimate and included in the sprint backlog”, but should not be taken into consideration when calculating the velocity of the team (see dictionary term “velocity”)

Seems to me that “spike” could potentially have two meanings: (a) a thin, pointed piece of metal, wood, or another rigid material (which, BTW, says nothing about it serving as an anchor); and (b) a sharp increase in the magnitude or concentration of something. Given that the two meanings are so divergent, why not use a different term that is more precise. I find it “funny” that methodologists — who should, if anything, be clear in the terms they use — persist in using words that are unclear. Why not call it “research”, “prerequisite”, or something like that?

I think this ties in with other terms such as “Agile”, “Scrum”, “Burn Down Chart” etc. It’s a way of appearing to have developed shiny new concepts (but actually repackaged concepts) in order to sell a new methodology.

After the time box is over, we re-asses what to do next. Often, the outcome is a more refined estimate for how much work the actual business objective will require. Sometimes the outcome of a spike is a decision to do another spike. Sometimes the outcome is a decision not to invest any more time investigating this particular question. The important thing about the time box is that it limits our investment, at least until we make a conscious decision to invest more.

About The Agile Dictionary

Welcome to iteration zero of The Agile Dictionary! Our goal with this project is to provide broad, authoritative definitions of common Agile terms. You will note that each definition also includes a section titled “etymology,” where we capture the origins of the term wherever possible.

Visit the definitions by clicking on the letters in the navigation bar, or you can search for a term, above.