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.
Background of the Term
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.”
Further Learning
What’s a Spike, Who should enter it, and how to word it? by Andrew Fuqua
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.
Paul: Thanks, that sounds very plausable, considering I was thinking it alluded to an “anchor” of some sort, not in the nautical sense, but as in climbing, a jumping off point.
That’s a good analogy. I was asked the same thing this morning and I likened the spike to a pin bursting open a balloon (User Story) so that it can be looked at in more detail.
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’.
Interesting thought. While it may be entirely true that the term was inspired by rock climbing, as a rock climber myself I can say that, to my knowledge, no climber anywhere has ever called them “spikes”. They say gear, protection, pro, pitons, ice screws, bolts, hangers, nuts, cams, friends, chocks, copperheads, hexcentrics, cowbells, etc. (referring to different types of equipment), but I’ve never heard of spikes. A piton is probably the closest to a spike in terms of shape and use. Just FYI.
Pingback: Retrospiketives | Rob Aston
Pingback: Retrospiketives | SoftDevine
Pingback: PEARL V : Scaled Agile Framework® pronounced SAFe™ | Pearls of Wisdom
Pingback: ¿Qué son las historias de usuario y por qué “invertir” en ellas? - Agiland, expertos en Metodologías Ágiles
Pingback: Yikes! Spikes! | My Agile journey
Pingback: Spike Time « Stok Footage
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 🙂
(“… everything that’s old is new again””
+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.
Pingback: Why Software Engineering Isn’t Engineering, and the Implications – Ian Cackett
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.
Pingback: Product Backlog Refinement Explained (2/3) | The Agile People Developer
Pingback: Product Backlog Refinement explained (2/3) - Scrum.org Community Blog
Pingback: Enhanced Scrum Guide | enhancedscrumguidedotcom
Pingback: Exiling a legacy COM component | Schneide Blog
Pingback: Yanado - Task management inside Gmail.
Pingback: Week 1 -Boris bikes and coding spikes – the code bug
Pingback: Spike Abuse | Adept Technologies
Pingback: The Ultimate Introduction To Agile Project Management | Repository of Knowledge
Pingback: The Ultimate Introduction To Agile Project Management - Balance SEO
Pingback: The Ultimate Introduction To Agile Project Management – Notes
Pingback: On Building Tools for Developers: Heroku CI | Rake™
Pingback: The 11 Agile Processes We Use to Run an Efficient Software Team | Process Street
Pingback: To spike or not to spike? – Zen Ex Machina – The blog
At the outset let me say that I am new to agile, hence I’m googling definitions.
…and I’m sure there’s an easy answer to the question below.
Something that interests me is, a spike is described as
“…time boxed effort toward understanding an unknown unknown…”,
what happens to spikes that run out of time without reaching the understanding?
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.
Cheers,
Chris
Pingback: agiLE#13 – Barcamp warmup – commodus.
Pingback: Bridging Waterfall and Agile teams – Ctrl Alt Dad
Pingback: How to get your backlog ready for PI Planning – Enterprise Agility Blogs…
Pingback: 스파이크 (Spike) • Agile Practices
Pingback: Moving forward after a Code Spike – ZAFU LABS
Another meaning of Spike – in the domain of journalism – is for stuff that has been rejected prior to publication, as described on Wikipedia. That was the meaning that sprang to my mind, although from the discussion it doesn’t seem particularly relevant.
Pingback: Applying product methodologies in data science – Yakanak News
Pingback: Applying product methodologies in data science – Data Science Austria
Throughout this thread I’ve seen arguments for giving spikes story points. What are the cons? Why was researching the implementation of a problem not included in the initial planning according XP?
My recommendation is to not give points to spikes. They are just part of the normal product backlog refinement work that team members do on an on-going basis. The exception is if the result of the spike is information that will be used by stakeholders outside the team. In that case, the spike is really just a story. That is, the team is creating something of value that has been requested by stakeholders.
I have heard about this term in my career for a while. I approximately knew what it means but never really understood why it’s called “Spike”.
Finding this out was… disappointing. Another instance of people using an unintuitive term as jargon to “sound serious/professional”. A new developer would have no idea what a spike is in 2022. Honestly, developers should just start calling it “research” or “prototyping”