What is a Spike in Agile?
A spike in agile is a short, time-boxed investigation that answers a specific question before you build. Here is when to use one, the two types, how to run it, and how it differs from a proof of concept.
A spike is a short, time-boxed piece of research that an agile team runs to answer a specific question before committing to build something. You’re not producing a feature. You’re buying knowledge — just enough to estimate the real work with confidence, or to choose between two approaches without guessing.
The term comes from Extreme Programming (XP), where the early teams used it to describe driving one focused effort straight through a problem to see what’s on the other side. If a user story is too fuzzy or too risky to estimate, you spike it first, then plan the actual work once you know more.
What a spike actually is (and isn’t)
Most confusion about spikes comes from treating them like normal development work. They aren’t. A regular story ends with something a user can use. A spike ends with an answer.
The one thing to remember: the deliverable of a spike is a decision or a piece of knowledge, not shippable code. If you finish a spike and all you can show is half-built production code, you’ve run a mini-project, not a spike.
That single shift in mindset changes how you scope the work, how you time-box it, and how you judge whether it succeeded. A spike is “done” when the question is answered and the team can act on it — even when the answer turns out to be “this approach won’t work.”
The two types of spike
Teams usually reach for one of two kinds, depending on what they’re unsure about.
Technical spikes
A technical spike tackles uncertainty in the how. Can this third-party API handle our load? Will this library work with our stack? Is the migration even feasible in the time we have? You might write some throwaway code, run a quick benchmark, or wire up a rough integration — whatever it takes to get a trustworthy answer.
Functional spikes
A functional spike addresses uncertainty in the what. How will people actually move through this flow? Which of two designs causes less confusion? What does the business genuinely need versus what it first asked for? These tend to involve sketches, a clickable prototype, or a short round of user feedback rather than backend code.
Plenty of real investigations are a bit of both, and that’s fine — the kind of joined-up thinking you’d expect in an agile organisation where business and delivery plan together. The label matters less than being clear about the question you’re answering.
When to use a spike, and when not to
Spikes are a normal part of healthy agile working, and they earn their place when uncertainty is blocking good planning. Reach for one when:
- A story is too vague or too risky for the team to estimate honestly.
- You’re working with an unfamiliar technology, API, or dataset.
- Two reasonable approaches exist and you can’t choose between them on paper.
- A requirement keeps shifting because nobody has tested the assumption behind it.
They become a problem when they turn into a hiding place. If the team already knows the answer, skip the spike and build. If someone proposes open-ended “research” with no question and no end date, that isn’t a spike — it’s scope creep in a costume. And a spike should never be a polite way to defer a decision the team is simply avoiding.
How to run a spike that doesn’t sprawl
The discipline is all in the constraints. A loose spike will happily eat a whole sprint. A tight one gives you an answer and gets out of the way.
- Write the question down. One or two specific, answerable questions. “Can we export 50,000 records to PDF in under ten seconds?” beats “look into PDF export.”
- Time-box it. Set a hard limit, often a day or two, that fits inside the sprint. When the clock runs out you stop and report what you found, even if the picture is incomplete.
- Decide what “done” looks like. The acceptance criteria for a spike are the questions answered and written up, not a working feature.
- Treat the code as disposable. Spike code exists to teach you something. Most of it should be thrown away, not quietly promoted into production.
- Share the findings. A spike that lives only in one person’s head is half wasted. A short write-up, a quick demo, or a few lines in the ticket lets the whole team plan the real work.
Get these constraints right and a spike stops being a risk to your sprint and becomes one of the most dependable tools you have — which is why disciplined investigation is built into accredited AgilePM® training.
Spike vs proof of concept vs prototype
These terms get used interchangeably, which muddies planning conversations. They overlap, but each answers a different question.
| Approach | Main question it answers | Typical output |
|---|---|---|
| Spike | “What do we need to learn before we can plan this?” | A documented answer or decision |
| Proof of concept | “Is this idea technically feasible at all?” | A narrow demo proving one thing works |
| Prototype | “How should this look and feel to use?” | A throwaway model of the experience |
In practice a spike might produce a small proof of concept or prototype along the way. The difference is intent: a spike is about reducing uncertainty so you can estimate and decide.
A quick example
Say a team wants to add live chat to a customer portal, but nobody’s sure whether to build it in-house or plug in a third-party service. Estimating the work is guesswork. So they run a two-day technical spike with one question: can the leading third-party widget meet our data-residency and accessibility requirements without custom work?
By the end they’ve tested the widget against both requirements, found a single accessibility gap, and written half a page on what integrating it would involve. They haven’t shipped chat. But the next planning session is no longer a debate — it’s a decision backed by evidence, and the build story can finally be estimated.
Common mistakes to avoid
- No clear question. A spike without a sharp question drifts forever.
- No time-box. “We’ll look into it” isn’t a plan. Set a limit and respect it.
- Shipping the spike code. Exploratory code rarely meets production standards; rebuild it properly once you know the answer.
- Keeping findings private. If the learning isn’t shared, the team can’t act on it.
Frequently asked questions
How long should a spike last?
Short enough to fit inside a single sprint, and usually much less — often a day or two. The point is a quick, focused answer, not an open-ended study. If a question genuinely needs longer, it’s probably several smaller questions in disguise.
Do spikes get story points?
Teams handle this differently. Some estimate spikes like any other backlog item so the time is visible in the sprint; others time-box them and assign a fixed, nominal size. What matters is that the effort is planned and capped, not hidden.
Who carries out a spike?
Whoever is best placed to answer the question — often a developer for a technical spike, or a designer and product owner together for a functional one. Pairing helps, since two people usually reach a trustworthy answer faster and the knowledge is shared from the start.
Is a spike the same as a research task?
It’s a specific kind of research task: time-boxed, tied to a concrete question, and aimed at making the next piece of work estimable. Generic “research” with no boundary is exactly what a spike is meant to replace.
The bottom line
A spike is one of the simplest tools in agile, and one of the easiest to misuse. Keep it short, give it a real question, treat the code as disposable, and share what you learn. Done well, it turns “we’re not sure” into “here’s what we found” — which is exactly the certainty good planning depends on.
If you’re building agile skills more broadly, learning the practices in a structured way helps ideas like this click sooner. Career Smarter’s accredited AgilePM® Foundation course covers how techniques like spikes fit into delivering real projects, and if you want to go further in one go, the combined AgilePM® Foundation and Practitioner route takes you through to the applied level.