What is a spike?

A spike is a time-boxed investigation, run when the team can't size a story without learning more. The output is knowledge — a doc, a prototype, a recommendation, a measurement — not shipped product code. The point is to come back with enough information to estimate the real story honestly.

Two things make a spike a spike rather than just unbounded work: a clock and a deliverable. A spike with no clock turns into the work. A spike with no deliverable produces nothing the team can act on. Both halves are non-negotiable.

When a spike is the right tool

• The team can't agree on size because nobody's done this before.
• The vendor's API isn't well-documented and the docs don't answer the load-bearing question.
• The story depends on a measurement nobody has yet (current p99, current call volume, current data shape).
• The fix depends on the diagnosis, and the diagnosis is itself unknown.

When a spike is the wrong tool

Spikes get misused as "let's just start working on this and see what happens." That isn't a spike — it's an unestimated story with extra steps. Two signals it's the wrong tool: there's no specific question being answered, or the deliverable is "the feature is built." The first means the team isn't actually unsure; the second means it's a story, not a spike.

Should spikes have story points?

No — they're time-boxes. The number on the card is a budget, not a forecast. Full answer.

See also: estimating a research spike for the worked example; SPIDR splitting uses Spike as one of its five cut lines.