Spikes Done Right: Buying Down Delivery Risk Without Turning It Into Research Theater

A spike buys information to make one specific decision, then it ends — it never ships a feature or becomes the implementation itself. Run one only when you can name the open question, cap the time spent, and state the decision the answer feeds. Skip any piece, and it becomes open-ended research.

A spike needs three things to work: an explicit question it's answering, a timebox that ends regardless of the outcome, and a named decision the answer will inform. Miss any one and "let's spike it" quietly becomes an open-ended research project with a ticket number.

Why Most Spikes Turn Into Research Theater

Spikes fail for one root reason: they get created as "let's go find out about X" without ever specifying what decision the finding-out serves. Without a decision attached, there's no natural stopping point, no way to judge whether the spike succeeded, and no owner accountable for using the answer.

You can usually spot research theater by its symptoms rather than its intent — nobody sets out to build a rabbit hole. It just accretes:

• The spike ticket carries over sprint after sprint with a shrug and a re-estimate.
• The output is a wiki page or a Slack thread, not something the team can act on.
• Nobody scheduled a moment to decide anything with the findings.
• The "quick investigation" quietly becomes the first draft of production code.
• Every answer produces three new sub-questions, and the team follows all of them.

Barry Boehm's Spiral Model named this dynamic back in the 1980s: the whole point of an early, risk-driven iteration is to spend a bounded amount of effort buying down uncertainty before committing real budget to a direction. Boehm's framing is blunt — you're not exploring for its own sake, you're purchasing information, and any purchase needs a price you're willing to pay and a stopping point. Spikes are the modern, story-sized version of that same idea, and they inherit the same discipline requirement.

Spikes sit inside a much wider set of levers for managing delivery risk, which the complete guide to agile delivery covers in full. What makes a spike specifically prone to sprawl is that it's the one delivery artifact explicitly permitted to produce no working software — which is exactly why it needs tighter guardrails than a normal story, not looser ones.

The Mental Shift: A Spike Buys Information, Then Dies

The fix for research theater isn't more process — it's a different mental model. A spike is not a mini-project; it's a transaction. You spend a fixed amount of time to purchase a specific piece of information, and once you've paid for it, the spike is over, whether or not the answer is the one you wanted.

Douglas Hubbard's work on the economics of uncertainty, How to Measure Anything, offers a useful test before you even open a spike ticket: is the cost of finding out less than the value of the decision it improves? If a technical unknown can't actually change what you build next, spiking it is just curiosity wearing a ticket number. Not every uncertainty deserves a spike — only the ones sitting on the critical path of a real decision.

This is also where a spike differs from ordinary discovery work. In a dual-track agile setup, the discovery track runs continuously and never really "finishes" — it's an ongoing rhythm of learning. A spike is a discrete, bounded transaction borrowed briefly from delivery capacity to answer one question the discovery track surfaced, then it hands the answer back and disappears. Conflating the two is a common source of open-ended spikes: teams treat a spike like a slice of the discovery track instead of a one-time purchase.

The Three-Part Rule: Question, Timebox, Decision

A well-formed spike names an explicit question, sets a timebox that expires no matter what, and states which decision — build vs. buy, architecture A vs. B, feasible vs. not — the answer feeds. Write all three into the ticket before starting; a spike missing any one of them isn't really a spike, it's just work with no exit condition.

The question has to be answerable, not open-ended

"Investigate the new payments provider" is not a spike question — it's a job description. "Can we authenticate against the new payments provider's sandbox and capture a card token in under 200ms?" is a spike question, because it has a yes/no or measurable answer. If you can't picture what a completed answer looks like on day one, the question isn't ready to spike yet; it needs to be narrowed first.

The timebox is a deadline, not an estimate

Treat the timebox as a commitment device, not a guess at effort. A normal story's estimate predicts how long work will take; a spike's timebox is a decision about how much you're willing to spend, made in advance and independent of how the investigation goes. The distinction is worth borrowing from the critique of why velocity and story points diverge from value — a spike measured by points burned rewards busywork, while one measured by "did we get an answer by the deadline" rewards focus.

The decision is named before the spike starts, not after

Every spike should be traceable to a sentence that starts with "if the answer is X, we will Y." If nobody can complete that sentence before work begins, stop — you don't have a spike, you have curiosity. Naming the decision also settles an ownership question that often stalls teams: per the boundaries in PM vs. PO role distinctions, decision criteria and the business call usually sit with product, while the feasibility verdict sits with engineering — the ticket should make clear which half owns the final call.

Technical Spikes vs. Functional Spikes: Different Questions, Different Tests

Technical spikes test whether something is possible — will this API handle the load, can two systems integrate, will a library fit our constraints. Functional spikes test whether something is desirable or usable — does this flow solve the user's job, does the concept fit how customers really work. The same three-part rule applies to both; only the question type and evidence bar differ.

A functional spike is, at its core, a fast and cheap test of a jobs-to-be-done hypothesis — you're checking whether a proposed flow actually helps someone make progress on the job they're hiring your product for, which is exactly the lens the complete guide to jobs-to-be-done walks through in depth. Run that test as a narrow spike rather than a full study, and you get a directional answer in days instead of weeks.

Functional spikes are also often the fastest way to pressure-test a single moment along the customer journey rather than commissioning research across the whole experience. If the open question is "does removing this confirmation step reduce drop-off at checkout," that's one journey moment, one hypothesis, one spike — not a full journey remap.

Technical spikes, by contrast, live closer to Kent Beck's original definition from Extreme Programming: a small, throwaway program built purely to answer one implementation question, explicitly not intended to survive into production. Beck's framing is worth keeping close, because the most common way a technical spike turns into research theater is that its throwaway proof-of-concept quietly becomes the real branch nobody rewrote.

Timeboxing That Actually Holds

A timebox only works if it's treated as a hard boundary decided in advance, not a soft estimate renegotiated as you go. Pick the smallest window that could plausibly answer the question, put a calendar date on it rather than a vague "this sprint," and decide before you start what happens if time runs out without an answer.

A few rules keep the boundary from eroding once work is underway:

1. Timebox the question, not the exploration space. Scope creep during a spike almost always shows up as "well, while I was in there, I also looked at..." — treat any tangent as a new, separately-scoped spike candidate, not free real estate inside the current one.
2. Default "inconclusive" to "no." If the timebox expires without a clear answer, that itself is information — it usually means the option is riskier or more complex than assumed, and the decision should treat it accordingly rather than granting an open-ended extension.
3. Allow exactly one extension, with a new decision attached. If more time is genuinely warranted, that's a fresh, explicit decision made by whoever owns the call — not a default that happens because nobody stopped the clock.
4. Keep the spike out of velocity. Don't let a spike get pointed and absorbed into the sprint's story points the way ordinary delivery work is — doing so quietly signals "size this like normal work," which is precisely the wrong incentive for something meant to be small and bounded.
5. Protect it from stakeholder gravity. A spike that produces an interesting demo tends to attract "can you also check..." requests mid-flight. Redirect those into the next candidate spike; answering them now defeats the timebox that made this one trustworthy in the first place.

The Standish Group's long-running CHAOS research has, across decades of surveys, repeatedly found something in the neighborhood of a third of software projects landing as full failures or cancellations, with unclear or shifting requirements consistently sitting near the top of the reasons cited. A disciplined spike is one of the cheapest tools available for catching that kind of ambiguity early, while it still costs days instead of months.

From Notes to Artifact: What a Spike Should Produce When It Ends

A spike should end with a decision record and, for technical spikes, a concrete, reusable artifact — a benchmark result, an integration contract, a proof-of-concept branch — not just a conversation and a Slack thread nobody can find again in three months. The artifact is what makes the decision durable enough for someone else to trust later without re-litigating it.

A lightweight decision record keeps the whole exercise auditable. It doesn't need a template heavier than this:

Where the artifact matters most

This is where technical spikes have a real advantage over "we talked about it in standup": a concrete artifact turns a fuzzy feasibility conversation into something the next engineer can pick up without re-deriving it. A benchmark number, a working curl call against a sandboxed endpoint, or a documented contract is worth more than a page of prose describing the same finding.

Key Takeaways

• A spike is a transaction, not a project — it buys a specific piece of information and then ends, whether or not the answer is the one you wanted.
• Three ingredients are non-negotiable: an explicit question with a measurable answer, a timebox fixed in advance as a deadline rather than an estimate, and a named decision the answer will feed.
• Technical spikes test feasibility; functional spikes test desirability and usability — same rule, different owner, different evidence, different typical timebox.
• Inconclusive results should default to "no" rather than triggering an automatic extension; treat a second round as a fresh, deliberate decision.
• Keep spikes out of velocity math — pointing them like ordinary stories rewards time spent instead of the clarity produced.
• End every spike with a decision record, and where possible a concrete artifact — a benchmark, a spec, a proof-of-concept branch — so the finding survives longer than the meeting where it was discussed.
• Not every uncertainty deserves a spike — only the ones sitting on the critical path of a real, near-term decision are worth the delivery capacity.