What is a Spike in Agile?

A spike in Agile is a time-boxed piece of work whose output is knowledge rather than a shippable increment (a working piece of the product). The team takes a question it cannot estimate or decide around: a technology choice, an unclear requirement, a feasibility risk. It investigates for a fixed period and comes back with an answer the next user stories can be built on.

The term comes from Extreme Programming. There, a spike solution is a quick, throwaway program written to drive through every layer of a problem — like a spike through a plank — just to see whether it can be done. Scrum and SAFe adopted the word, and today most teams use it for any investigation that has a time box and a question to answer.

This article covers what spikes are for, when to use one, the types, how to write and time-box a spike story, and how to stop spikes quietly eating the sprint.

The primary purpose of a spike is to gain knowledge and insight into an unknown or complex aspect of the project. This could be related to technical challenges, new technologies, or unclear user stories that require further clarification. Spikes help reduce ambiguity by allowing teams to explore solutions or conduct research that informs subsequent tasks and decisions.

Spikes often address questions like:

By addressing these questions through a spike, teams can avoid wasted time on approaches that may not work and ensure smoother progress later in the development cycle.

In Agile development, spikes are used when the team encounters a situation where additional information or a decision is needed before moving forward. They are typically time-boxed, meaning they are given a fixed duration (often one or two days) to ensure that they don't delay progress unnecessarily.

Some scenarios when a spike might be needed include:

There are two main types of spikes in Agile:

1. Technical Spike: This is focused on exploring technical issues, such as choosing the right framework, technology, or tool. For instance, a technical spike might investigate how to integrate a new API or test a new piece of software.

2. Functional Spike: This type of spike is aimed at gathering more information about user requirements or behaviors. It could involve investigating how a user interacts with an interface or how a feature should behave in certain conditions.

A spike is written like a user story but judged by a different standard: it is done when the question is answered, not when something ships.

• Title it as the question. "Can we stream exports through the existing API gateway without buffering?" beats "Investigate export streaming" — the question makes the finish line visible.
• Put the time box in the first line. A day or two is typical; anything longer than a sprint is a project, not a spike.
• Make the acceptance criteria the decision. "A written recommendation with the trade-offs, reviewed with the team" — not "prototype works". The prototype, if there is one, is thrown away.
• Name the stories it unblocks. A spike that unblocks nothing is research for its own sake and belongs in a backlog of its own.
• Leave the answer where the next person will look. A short write-up or decision record on the ticket, not in the head of whoever did the work.

Spikes should be approached with a clear structure to maximize their effectiveness. Here’s how to implement a spike in an Agile environment:

1. Define the Goal: Clearly identify what the spike is trying to achieve. This could involve determining the technical feasibility of a solution, clarifying user requirements, or investigating potential risks.

2. Time-box the Spike: Assign a specific time limit to the spike to ensure it doesn't take up excessive resources. This might range from a few hours to a few days, depending on the complexity of the problem.

3. Conduct the Research or Experimentation: During the spike, the team performs the necessary research, tests solutions, or investigates the unknowns. This may include reviewing documentation, experimenting with code, or discussing with subject matter experts.

4. Share Findings: Once the spike is complete, the team should share the results. This could be in the form of documentation, a presentation, or a demo of a prototype. The goal is to provide the team with enough knowledge to move forward with confidence.

5. Update the Product Backlog: The insights gained from the spike should be used to refine the user story or the technical task. If the spike reveals new requirements, these should be added to the product backlog for further refinement.

Should spikes get story points? Teams disagree, and both answers work as long as they are applied consistently. SAFe’s guidance is to estimate spikes like any other backlog item so their cost is visible; many Scrum teams leave them unpointed and reserve a slice of capacity instead. The mistake is letting spikes float outside the plan altogether: they then consume capacity that velocity never accounts for, and the sprint looks slower than it was for no visible reason.

Whatever the convention, watch how much of each sprint goes to spikes. A small, steady share is a team doing its homework. A rising share is a backlog whose stories are not ready: a refinement problem wearing a research costume. It is the early form of every problem in the risks and drawbacks of spikes — scope creep, overuse, spikes that end without a decision. Sprint Insights in Agile Analytics classifies tickets into feature and non-feature work automatically, so that share is visible per team without anyone tagging anything.

A spike in Agile is a powerful tool for managing uncertainty and risk within a project. Whether it's a technical investigation or a clarification of user requirements, spikes help teams move forward with confidence and clarity. By incorporating spikes into your Agile process, you can ensure that your team has the right information to make informed decisions and avoid pitfalls that could cause delays.

Spikes help reduce uncertainty, improve decision-making, foster innovation, and encourage collaboration within the team. Additionally, they ensure that teams avoid wasting effort on unclear solutions by providing the knowledge needed to choose the best path forward. By reducing risk and increasing the accuracy of decisions, spikes lead to smoother project execution and ultimately better outcomes.

A spike is, by definition, work that does not ship a feature — and that is exactly the work a sprint report tends to lose. Agile Analytics reads your team's progress from the data your existing tools already produce, so the time spent investigating is visible rather than reconstructed by hand. Its Sprint Insights separate feature development from maintenance and other non-feature work.

If that is a number you have been estimating, book a demo and see it against your own delivery data.

Is a spike a user story? It sits in the backlog and the sprint like one, but it is not one: a user story delivers value to a user, a spike delivers a decision to the team. Some tools give it its own issue type; a label on an ordinary story works just as well.

How long should a spike take? As short as will answer the question — a few hours to two days is typical. Fix the time box before starting and stop when it ends, even without a complete answer. "We still don’t know, and here is why" is a valid result; it usually points to a smaller, sharper spike.

What is a research spike? A feasibility spike? Names for the same thing by what is being asked. A research spike surveys options (which message queue?); a feasibility spike tests whether one option can work at all (can this library handle our volume?); a functional spike clarifies what users actually need. All are time-boxed, all end in a decision.

Does a spike produce working software? Sometimes a throwaway prototype, never a shippable increment. Code written in a spike is written to learn, not to keep. If it turns out good enough to ship, that is a bonus — and it still goes through normal review first.

What is spike-driven development? Not a formal method. It usually describes a team that runs a spike before committing to any story with real uncertainty, so estimates rest on knowledge rather than hope. Used with judgement it is good practice; used for everything it is the overuse problem in disguise.