Skip to content

Spike Management

A time-boxed investigation when the team cannot estimate without learning something first. 2–5 days, with a written conclusion. Not a story. Not a feature. Not a deliverable. A learning artefact whose output is a decision.

Owners: Tech Lead, Developer Phase it lives in: Before We Build → What We Build The corpus principle this enacts: Witnessed, not described — including the technical landscape.

Where it lives in the chain

How to do this

A spike has:

  1. A question. "Can we trigger Provider X's webhook from the staging environment, and what's the retry behaviour when we reject it?" Specific. Falsifiable.
  2. A timebox. 2 days. 5 days. Not "until we're done."
  3. A definition of done. "We have a written answer to the question, with evidence." Not "we've built a prototype."
  4. A named author. One developer or pair. Not a whole team.
  5. A written conclusion. Markdown, in the repo, linked from the ADR. Even if the conclusion is "we couldn't get a clear answer; here's what we tried."

Spike vs POC vs Prototype

TypeQuestionOutputLives in
Spike"Is this feasible / what's the constraint?"Written conclusionRepo / Confluence
POC"Does this approach work end-to-end at toy scale?"Throwaway codeBranch, deleted after
Prototype"Does this feel right to the user?"UI artefactFigma, throwaway

All three are disposable on purpose. The chain's discipline: the artefact whose output is a decision is not the artefact that ships. When a POC turns into a feature, the team has skipped shaping — and the shape they ship is the shape they prototyped, not the shape the feature needed.

What good practice looks like

A spike output is one page: question, what we tried, what we learned, the recommended decision. Read in the amigos session. Referenced from the ADR. No story is pulled while a spike on the same area is open. The cost of starting work before the spike concludes is the cost of throwing the work away when the spike contradicts the assumption.

200apps · How We Work · NWIRE