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

This entry was posted in s. Bookmark the permalink.

50 Responses to Spike

  1. Al says:

    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.

  2. Gary says:

    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).

  3. Paul says:

    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.

    • Keith Patton says:

      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.

    • David Patrick says:

      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.

      • Jon Jorgensen says:

        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.

        • Mike Aniskovich says:

          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.

    • Nitesh says:

      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 .☺️

      • Rick Waters says:

        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’.

    • Troy says:

      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.

  4. Pingback: Retrospiketives | Rob Aston

  5. Pingback: Retrospiketives | SoftDevine

  6. Pingback: PEARL V : Scaled Agile Framework® pronounced SAFe™ | Pearls of Wisdom

  7. Pingback: ¿Qué son las historias de usuario y por qué “invertir” en ellas? - Agiland, expertos en Metodologías Ágiles

  8. Pingback: Yikes! Spikes! | My Agile journey

  9. Pingback: Spike Time « Stok Footage

  10. Bob F says:

    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 🙂

    • Lisa says:

      (“… everything that’s old is new again””

    • Graham P says:

      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.

  11. Pingback: Why Software Engineering Isn’t Engineering, and the Implications – Ian Cackett

  12. Ken says:

    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.

  13. Razvan Grigorescu says:

    “… 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”)

  14. Steve Wehba says:

    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?

    • Dene Bebbington says:

      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.

  15. Pingback: Product Backlog Refinement Explained (2/3) | The Agile People Developer

  16. Pingback: Product Backlog Refinement explained (2/3) - Scrum.org Community Blog

  17. Pingback: Enhanced Scrum Guide | enhancedscrumguidedotcom

  18. Pingback: Exiling a legacy COM component | Schneide Blog

  19. Pingback: Yanado - Task management inside Gmail.

  20. Pingback: Week 1 -Boris bikes and coding spikes – the code bug

  21. Pingback: Spike Abuse | Adept Technologies

  22. Pingback: The Ultimate Introduction To Agile Project Management | Repository of Knowledge

  23. Pingback: The Ultimate Introduction To Agile Project Management - Balance SEO

  24. Pingback: The Ultimate Introduction To Agile Project Management – Notes

  25. Pingback: On Building Tools for Developers: Heroku CI | Rake™

  26. Pingback: The 11 Agile Processes We Use to Run an Efficient Software Team | Process Street

  27. Pingback: To spike or not to spike? – Zen Ex Machina – The blog

  28. shaun says:

    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?

    • Chris Sims says:

      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.



  29. Pingback: agiLE#13 – Barcamp warmup – commodus.

  30. Pingback: Bridging Waterfall and Agile teams – Ctrl Alt Dad

  31. Pingback: How to get your backlog ready for PI Planning – Enterprise Agility Blogs…

  32. Pingback: 스파이크 (Spike) • Agile Practices

  33. Pingback: Moving forward after a Code Spike – ZAFU LABS

  34. Nev says:

    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.

  35. Pingback: Applying product methodologies in data science – Yakanak News

  36. Pingback: Applying product methodologies in data science – Data Science Austria

  37. Victoria Mears says:

    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?

    • Chris Sims says:

      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.

  38. Kaidong Nie says:

    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”

Leave a Reply

Your email address will not be published. Required fields are marked *