A Spike is a time-boxed piece of work aimed at answering a specific question or reducing a specific uncertainty, rather than delivering a piece of the product itself. It's not formally defined in the Scrum Guide, but it's widely used, and understanding what makes it different from ordinary backlog work clarifies when it's the right tool and when it's an excuse to avoid making a decision.
What a Spike is for
A Spike exists to answer a question that's currently blocking confident estimation or planning: is this third-party API capable of what's needed, which of two technical approaches is actually feasible, what's the rough scope of an unfamiliar problem area. The output of a Spike isn't a shippable increment; it's information: an answer, a recommendation, or at minimum a much better-informed understanding of the problem than existed before the Spike started.
Why it needs a strict time box
Without a firm time limit, investigative work tends to expand to fill whatever time is available, because "just a bit more research" always feels justified when the goal is understanding rather than a concrete deliverable. A Spike time-boxed to, say, two days forces a decision at the end of those two days: either enough is now known to proceed with confidence, or it isn't, in which case that's itself useful information about the genuine difficulty of the problem, not a reason to simply extend the investigation indefinitely.
The discipline of a good Spike
A specific question, stated before the Spike begins. "Investigate the new payment API" is too vague to know when the Spike is done. "Determine whether the new payment API supports partial refunds, and if not, what workaround would cost" is specific enough that the Spike has a clear end condition.
A concrete output, not just accumulated understanding. A good Spike concludes with a written recommendation, a proof-of-concept, or a clear answer: something the rest of the team can act on without needing to personally relive the investigation.
A genuine decision point at the end. The team should use the Spike's output to actually decide something: proceed with approach A, size the now-better-understood work at a specific estimate, escalate a genuine blocker. A Spike whose findings never actually change any subsequent decision wasn't worth doing in the first place.
When Spikes get misused
The most common misuse is a Spike that quietly becomes actual product development: the "investigation" produces code that ends up shipped directly, without going through normal estimation, review, or Definition-of-Done scrutiny, because it was "just a Spike." This undermines the very estimation process the Spike was meant to inform.
The other common misuse is using Spikes to indefinitely avoid a decision that's genuinely just uncertain rather than genuinely unresearched: running Spike after Spike on a problem that additional investigation won't meaningfully clarify, because at some point the team has to accept the uncertainty and make a call rather than keep investigating in the hope that certainty will eventually arrive.