A spike, or sprint spike, is a deliberate pause for learning. A short, time‑boxed piece of work the team uses when they’ve hit a “we don’t know what we don’t know” moment. Or a way to experiment, investigate or understand something. Instead of guessing or hoping, a spike gives you space to explore, experiment and reduce uncertainty before committing to a full solution or more permanent change.
The idea originated in Extreme Programming (XP), where it was used as a metaphor of driving a spike into the ground to test whether it would hold. If the spike is solid, you can build on it. If not, you’ve saved yourself from constructing something on shaky foundations. The same principle applies in software. Prove the concept first, then build with confidence.
To stay useful, spikes need a little discipline. The best ones are time‑boxed, have a clear purpose and outcome, and are reversible. Think of them as a sketch, not an oil painting. Quality Engineers and professionals like spikes because they are low-risk and potentially high-reward. A spike lets you “test the idea” first. They can expose hidden dependencies, highlight awkward integrations, prove or disprove theories, and identify architectural unknowns long before they become late‑sprint surprises.
At their heart, spikes are a strategic pause, a reminder that sometimes the fastest way forward is to stop, learn and remove the unknowns. They turn “we think this will work” into “we know how this will work, and here’s the evidence.”
