Technical spike

A technical spike is a focused, time-boxed investigation designed to answer specific technical questions or reduce uncertainty before committing to larger implementation work. The team carves out dedicated time - typically one or two days within a sprint - to explore an unknown, prototype an approach, or evaluate options. The output isn't shippable code but knowledge that enables better decisions.

Why it matters

Uncertainty kills estimation. When a team faces a story that could take two days or two weeks depending on factors nobody understands, planning becomes guesswork. Technical spikes convert unknowns into knowns, enabling realistic estimates and informed architectural decisions.

Spikes also prevent expensive mistakes. Discovering halfway through implementation that your chosen approach won't work wastes significant effort. A spike that surfaces this problem in two days instead of two weeks saves the team from building something that needs to be thrown away.

When to use spikes

Technical spikes make sense when uncertainty is high enough to justify the investment:

New technology adoption. Before committing to a new framework, library, or service, a spike explores how it actually works in your context. Documentation and tutorials only go so far; hands-on investigation reveals the real integration challenges.

Architectural decisions. When multiple approaches could work and the team can't agree on which is best, a spike provides evidence. Build small prototypes of each approach and evaluate against real requirements.

Performance unknowns. If you're uncertain whether an approach will meet performance requirements, a spike lets you measure before committing. Better to discover scaling problems in a prototype than in production.

Integration complexity. Connecting with external systems often brings surprises. A spike explores the actual API behavior, authentication requirements, and edge cases before the team builds on assumptions.

Estimation support. When a story feels too uncertain to estimate confidently, a spike investigates the specific unknowns that make estimation difficult.

Running an effective spike

Good spikes share several characteristics:

Clear question. Define specifically what you're trying to learn. "Can we integrate with the payment provider's webhook system in a way that handles failures gracefully?" is better than "explore payment integration."

Time-box. Set a fixed duration - one day, two days, at most a sprint. When time runs out, you stop and share what you learned, even if questions remain. Spikes can expand indefinitely without constraints.

Defined output. Know what you'll produce: a brief document, a demonstration, a decision recommendation. The spike doesn't create production code but does create shareable artifacts.

Right people. Assign developers who have the relevant skills and will work on the subsequent implementation. They need to carry the knowledge forward.

Spike vs. prototype vs. poc

Related terms sometimes blur together:

Spike - Focused investigation to answer specific questions. Output is knowledge, not code intended for production.

Prototype - Working model that demonstrates how something could work. May be more polished than a spike but still exploratory.

Proof of Concept (POC) - Demonstrates that an approach is feasible. Often more complete than a spike, sometimes involving multiple components working together.

In practice, the boundaries are fuzzy. A spike might produce a prototype. A POC might start as a spike that expanded. The key distinction is intent: spikes are about learning enough to make decisions, not about producing artifacts for their own sake.

Spikes in sprint planning

Teams handle spikes in planning differently:

Sized spikes. Some teams estimate spikes like any other story, using points or hours. This helps capacity planning but can feel awkward since the output is knowledge rather than features.

Unsized spikes. Other teams don't size spikes, instead allocating a fixed capacity (perhaps 10% of the sprint) for research activities. This acknowledges that discovery work is fundamentally different from implementation.

Spike-to-story pipeline. Spikes often produce follow-up stories for actual implementation. The spike outputs should include recommended next steps that get added to the backlog.

Documenting spike results

Spikes produce knowledge that needs to be captured. Without documentation, the learning stays in one developer's head and dissipates over time.

Effective spike documentation includes:

This documentation doesn't need to be formal. A wiki page, a detailed ticket comment, or a brief presentation all work. The goal is preserving the knowledge for future reference.

Common pitfalls

Several patterns reduce spike effectiveness:

Vague scope. "Explore authentication options" could take a week or a month. Narrow the question: "Can we use Auth0 with our existing user model, and what would migration require?"

No time-box. Without constraints, spikes expand. "Just a couple more days" becomes weeks. Set a time-box and stick to it.

Lost knowledge. A spike produces valuable learning that vanishes if the developer moves on without documenting. Build documentation into the spike expectation.

Spike addiction. Some teams spike everything, using research as a way to avoid committing. Spikes address genuine uncertainty, not normal implementation risk.

Wrong people. Assigning a spike to developers who won't do the subsequent work wastes knowledge transfer time and misses the opportunity for implementers to build intuition.

The product manager's role

Product managers don't run spikes but influence them:

Prioritizing research. When the team proposes a spike, understand why it matters. What decisions does it enable? What risks does it mitigate? Help prioritize research alongside feature work.

Defining success criteria. Help articulate what a successful spike would answer. Business context often shapes which questions matter most.

Acting on results. When a spike recommends an approach or reveals a problem, help the team incorporate those findings into plans. Spikes are wasted if their conclusions are ignored.

The modern context

Modern product development embraces uncertainty rather than trying to eliminate it through up-front planning. Spikes fit this philosophy by treating uncertainty as a normal part of work that deserves explicit attention.

In continuous discovery approaches, research activities happen throughout development rather than only at project start. Technical spikes complement user research spikes that explore customer needs. Both reduce different types of uncertainty that could derail delivery.

Tools like Klero help teams connect technical decisions to customer impact. When a spike explores alternative approaches, understanding which approach better serves validated customer needs helps teams make better choices - ensuring technical exploration stays grounded in actual value delivery.