Spike Investigation Time Points

Spike: timeboxed investigation before implementation

A spike is a timeboxed investigation card whose deliverable is knowledge — a proof-of-concept, a benchmark, a decision document — rather than working production code. The term comes from Extreme Programming (XP); Ron Jeffries introduced it as "a quick experiment that lets us learn about a problem domain", and Kent Beck formalised it in Extreme Programming Explained. Sizing in points or hours uses the same calculation as any other card: duration = points × hours_per_point — but the box is the maximum, not the goal.

Typical spikes last 1 to 3 days. Two flavours exist: architectural spikes (will this library / pattern work?) and risk spikes (we don't know enough to estimate the real story). The output should always be small and disposable — a doc, a throwaway branch, a notebook. If a spike grows beyond its timebox, that itself is evidence: the problem is bigger than expected, and the real story needs to be re-scoped before committing.

Applications

De-risking a story with unknown unknowns before refinement, library and framework evaluation, performance benchmarks, integration probes with third-party APIs, and producing the inputs needed to estimate the real implementation story with confidence.

FAQ

Should spike code be shipped? No. Spike code is throwaway by design — shipping it bakes in the shortcuts you took during exploration.

How long should a spike be? Strictly timeboxed — typically 1 to 3 days. If you need more, plan a second spike with a refined question after reviewing what the first uncovered.

Are spikes points or hours? Either works. Some teams use story points (treating them like any other card in velocity); others prefer raw hours to keep the timebox explicit. Pick one convention and stay consistent.