What is an Agile Spike?

An agile spike is a timeboxed piece of research a team takes on when they cannot estimate a backlog item because they do not know enough yet. The spike answers a specific question, the timebox stops it running on, and the output is knowledge rather than shippable functionality.

Key Highlights

• A spike exists to remove uncertainty, not to build something. If it produces working functionality, it was not a spike.
• Two types: a technical spike answers a how question, and a functional spike answers a what question about user behaviour or requirements.
• The timebox is the defining constraint. A spike without one is just unbounded investigation, and it will consume whatever time it is given.
• Every spike needs a written question and a definition of what answering it looks like. Investigate the payment API is not a spike.
• Spikes are estimated and pulled into the Sprint like any other item, so they consume capacity that would otherwise go to delivery.
• The most common misuse is running a spike because the backlog item was never properly refined, which hides a refinement problem rather than solving it.

What a Spike Actually Is

The term comes from the idea of driving a spike through a problem to see how deep it goes. You are not building the structure, you are probing it to find out what you are dealing with.

In practice a spike is a backlog item whose deliverable is an answer. The team spends a fixed amount of time investigating something specific, and at the end they know enough to estimate and plan the real work. The code written during a spike is usually thrown away, and that is the intended outcome rather than a failure.

The distinction that matters is between a spike and normal development work. Normal work has a known approach and an uncertain amount of effort. A spike has an unknown approach, which is why estimating it is impossible until the investigation is done. When a team says they cannot size an item because they do not know how they would build it, that is the signal a spike might be warranted.

Spikes appear in the Product Backlog alongside everything else, get ordered by the Product Owner, and get pulled into a Sprint by the Developers in the normal way. They are not a separate process running beside Scrum.

If you are working through Scrum practices and want to check where your understanding sits, our free CSM practice test covers the framework quickly and shows the gaps.

The Two Types

Technical spike. Answers a how question. Can this library handle our load. Will this integration work with our authentication. How long does a migration of this size actually take. The output is usually a small experiment, a benchmark, or a throwaway implementation that proves or disproves the approach.

A technical spike is the more common type and the easier one to scope, because the question tends to be concrete and the answer is usually observable. You either got the API responding within the latency budget or you did not.

Functional spike. Answers a what question about the product or the user. How do users currently work around this problem. Which of two workflows do people find easier. What does the reporting actually need to show to be useful. The output is research, a mockup tested with users, or a clickthrough prototype.

Functional spikes are harder to timebox because the question is softer, and they are more prone to expanding. The discipline of writing down what answering the question looks like matters more here than anywhere else.

Some teams distinguish a third category for architectural work, though this is really a technical spike with a wider blast radius. The question is the same shape: what approach should we take, and what evidence do we need before committing.

When a Spike Is Justified

Four conditions, and a genuine spike usually meets at least two of them.

The team cannot estimate the item at all. Not disagreeing between five and eight points. Genuinely unable to size it, because the approach is unknown. Estimation techniques like planning poker work when there is a shared mental model of the work, and they break down when there is not.

Two or more approaches exist and the choice is expensive to reverse. Picking a data store, an integration pattern or a framework is worth an afternoon of investigation, because getting it wrong costs weeks.

A dependency or a third party is unknown. New vendor API, unfamiliar internal service, undocumented legacy system. A short spike to confirm it behaves as advertised prevents a Sprint being derailed in week two.

The requirement itself is uncertain. Not the implementation, the thing being asked for. If nobody can say what good looks like, building it is guesswork, and a functional spike is cheaper than a wrong feature.

What all four have in common is that the uncertainty is real and the cost of proceeding without answering it is high. That is the test.

When It Is Not a Spike

This is where most of the damage happens, and each of these is common enough to recognise.

The item was never refined. If the team cannot estimate because nobody has discussed the item, the fix is backlog refinement, not a spike. Running a spike here treats a process problem as a technical one, and the same thing will happen next Sprint.

The team is avoiding a difficult item. Spikes get used to postpone work that feels hard but is actually understood. The signal is a spike whose question, written down, turns out to be something the team could already answer.

It is really just development work. If the team knows how to build it and the spike would produce the actual implementation, that is not a spike, it is the item with extra steps. The tell is that nobody plans to throw the output away.

Nobody defined a question. Investigate the reporting module is not a spike. Determine whether the reporting module can produce a monthly export within thirty seconds is. Without a question there is no way to know when the timebox has succeeded or failed.

It happens every Sprint. One or two spikes occasionally is healthy. A team running spikes continuously usually has a refinement problem, an architecture problem, or a Product Owner who is bringing items too early.

The output is a document nobody reads. If the spike produces a report that gets filed and never informs a decision, the investigation was not tied to a real choice.

Spotting which of these is happening is usually a Scrum Master job, because the team is often too close to it to notice. The distinction between genuine uncertainty and avoidance is one of the more useful judgements the role involves, and it is covered directly in CSM Certification Training.

The Rules That Keep a Spike Honest

Timebox it, and mean it. Two days, one day, half a Sprint at the absolute outside. When the timebox expires, the spike ends whether or not the answer arrived. That feels wrong the first time and it is the entire point, because an unbounded spike is just uncontrolled work. The same discipline applies here as to any other timeboxed activity in agile.

Write the question down. One sentence, specific enough that someone else could tell whether it was answered.

Define what an answer looks like. Before starting. A benchmark number, a working call to the API, a decision between two options with reasoning. This is the spike's Definition of Done, and without it the spike ends when someone loses interest.

Expect to throw the code away. Spike code is not production code. It skips error handling, tests and edge cases deliberately, because its job is to answer a question quickly. Letting spike code into production is a reliable way to accumulate technical debt.

Produce something the team can act on. A short written finding, a recommendation, or a revised estimate for the original item. The point is the decision it enables.

Report the answer even when it is negative. Discovering an approach will not work is a successful spike. Teams that treat a negative result as failure end up with people quietly extending the timebox to find a positive one.

Estimating and Sizing

A common question, and the answer is less complicated than it appears.

Spikes are estimated in the same units as everything else, but the estimate reflects the timebox rather than the work. If the team agrees to spend two days investigating, the spike is sized at whatever two days of effort looks like in their scale. You are not estimating how long the answer takes to find, because that is unknowable. You are estimating the box.

This matters for capacity. A team that commits three points to spikes has three points less for delivery that Sprint, and pretending otherwise produces a Sprint that quietly under delivers. Some teams size all spikes identically, which works well because it removes a pointless debate. The principle holds regardless of the scale in use, so story points and the other standard agile estimation techniques all handle spikes the same way.

One practical caution on velocity. Spikes complete and count toward velocity while producing no shippable output, so a Sprint heavy with spikes looks normal on a burndown while delivering nothing to users. Worth being aware of when reading the numbers, and a good reason not to load several spikes into one Sprint.

Writing a Spike

A workable format, kept deliberately short.

Question. Can our current search index return results for a two million record catalogue within four hundred milliseconds.

Why it matters. The catalogue expansion depends on this. If the answer is no, we need a different search approach and the epic changes shape.

Timebox. Two days, one developer.

What an answer looks like. A benchmark against a representative dataset, plus a recommendation on whether to proceed with the current index or evaluate alternatives.

Output. A short written finding shared with the team, and a revised estimate for the catalogue expansion item.

That is enough. Spikes do not need elaborate documentation, and a spike whose description runs to a page is usually one that has not been thought through.

What Happens After

The step teams most often skip. A spike that ends without a decision was wasted.

Share the finding with the team. Briefly. A few minutes in the next refinement session is usually enough, and the whole team benefits from knowing what was learned.

Re-estimate the original item. This is the primary purpose. The item that could not be sized should now be sizable, and if it still cannot be, that is important information in itself.

Update the backlog. The finding may split the item, change its order, or remove it entirely. All three are legitimate outcomes, and a spike that reveals an item is not worth building has saved more than it cost.

Record the decision, not the process. A short note on what was chosen and why is worth keeping. A detailed account of the investigation usually is not.

Delete the spike code. Or clearly mark it as throwaway. Spike branches that linger get picked up months later by someone who assumes they were production quality.

A Worked Example

The same situation handled two ways makes the difference concrete.

The version that works. A team needs to add offline support to a mobile app. Nobody has done it before, the estimates range from three points to twenty one, and the discussion in refinement goes in circles.

They write a spike. Question: can we sync local changes back to the server without conflicts using the library we already have, for the three data types the feature touches. Timebox: two days, two developers pairing. What an answer looks like: a working sync of one data type, plus a written view on whether the same approach extends to the other two.

Day two, they have it syncing one data type and have hit a conflict resolution problem the library does not handle. They stop at the timebox, write four paragraphs, and delete the branch.

In refinement the item gets re-estimated at thirteen points and split into three, with conflict handling pulled out as its own item because it turned out to be the hard part. The Product Owner decides two of the three are worth doing now.

Total cost: four developer days. Value: an estimate the team believes, a split that reflects the real work, and a scoping decision made with evidence.

The version that fails. Same situation. The team agrees to look into offline support. No written question, no timebox, one developer assigned.

Week one, they read documentation and try three libraries. Week two, they have a partial implementation working for one data type and are pushing on because it feels close. Nobody asks for a status because the work is clearly progressing.

Week three, the Product Owner asks when the feature will be ready. The developer has code that half works, no view on whether the approach scales, and has effectively started building the feature without an estimate or a plan. The code eventually ships, conflict handling included as an afterthought, and it produces support tickets for a year.

Total cost: fifteen developer days and a quality problem. Value: unclear.

The difference was not skill or effort. It was the question, the timebox and the willingness to stop.

Spike, Prototype, Proof of Concept

These overlap and get used interchangeably, which causes confusion in planning.

The practical difference is intent. A spike exists to unblock planning, so it ends when the question is answered. A prototype exists to explore an idea and may run longer. A proof of concept exists to convince someone, often outside the team.

In Scrum terms only the spike has a defined place, because it is a backlog item like any other. The others may happen inside a spike, but the spike is the container and the timebox is what makes it manageable.

How Many Spikes Is Too Many

A rough guide rather than a rule. One spike in a Sprint is normal. Two is worth a conversation. Three or more consistently means something upstream is broken.

The causes are usually one of the following. Refinement is happening too late or without the right people. The Product Owner is bringing items before they are understood, which is covered in the discussion of the Product Owner's part in Sprint Planning. The team is working in an unfamiliar domain, which is legitimate but temporary. Or the architecture is opaque enough that every change requires investigation, which is a technical debt problem wearing a different hat.

Noticing the pattern is a Scrum Master responsibility, and raising it as an impediment rather than accepting it as normal is part of what the role is for. Diagnosing this kind of upstream cause is covered practically in CSM Certification Training.

Closing Thoughts

The value of a spike comes almost entirely from the constraints around it. A written question, a fixed timebox, and a clear statement of what an answer looks like turn open ended investigation into something a team can plan around.

Remove any one of those and it stops working. No question and the spike drifts. No timebox and it expands. No definition of an answer and nobody can say when it is finished.

The other thing worth watching is frequency. Occasional spikes mean a team is dealing honestly with genuine uncertainty. Constant spikes usually mean items are reaching the Sprint before they are ready, and the fix for that sits in refinement rather than in better spikes.

If you are building the facilitation and diagnostic skills to spot that pattern and act on it, CSM Certification Training covers the framework and the practices that surround it, including how to handle uncertainty without letting it stall delivery. Request the curriculum to see the agenda and upcoming dates, or start with the free CSM practice test to see where you stand.