The 90% Untrue but 100% Useful Origin Story of the “Spike” in Agile

If you’re doing any kind of agile software development you’re making “spikes” for little bits of research, proofs of concept, or whatever you need to figure out cheaply before committing to real development. There are different versions of how the “spike” got its name. The one I love to use is most assuredly not true, but it is the best analogy I’ve heard…

Rock Climbing

When someone is “lead-climbing” on a rock face, they add protection as they go, clipping their rope into loops attached to the rock face. Before clipping in to the next protection, risk increases rapidly, as your fall doubles your climb: first you fall the distance above the protection, and then you fall the same distance further from the slack in the rope.

How far a climber will go before stopping to ensure protection depends on how risky the climbing feels. If they’re likely to fall, they might clip in sooner to make the risk more affordable.

Now, in the old days, before removable protection, if you were the first to climb a route, adding protection literally meant driving a spike into the rock.

(Yvon Chouinard, the founder of Patagonia, got his start by blacksmithing climbing spikes.)

And that’s how I think about spikes in the backlog. When the next move feels too technically risky on its own, a spike helps insulate uncertainty from consequence. This makes the risks affordable and leads to safer bets with the stories that follow.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Taj Moore

Taj Moore


Domain expertise in product management. Technology expertise in people. “I’m just here for the transformation.”