Spike
In short
A spike is a short, timeboxed investigation an Agile team does to answer a question or reduce uncertainty before committing to build a feature.
What is a spike in Agile?
A spike is a small, timeboxed piece of research that a team does to answer a question before committing to real work. Instead of delivering a feature, a spike delivers knowledge, for example whether the database can handle a new query volume, which library fits a need, or how a third-party API handles authentication. The term comes from Extreme Programming, where a spike solution is a very simple program written to explore a possible approach, like driving a spike through the whole problem to see what is underneath.
The team adds the spike to the backlog as an item with a clear question, a timebox of a few hours to a few days, and an expected output, such as a recommendation, a rough estimate, a short write-up, or a throwaway prototype. When the time runs out, the work stops and the team shares what it learned, even if the answer is that more information is needed. Technical spikes explore technology choices and risks, while functional spikes explore how a feature should behave for users.
A spike is like a geologist drilling a test hole before engineers design a building's foundation: it costs little compared with discovering bad soil once construction has started. Spikes are most useful when a user story can't be estimated because too much is unknown; after the spike, the team can split and estimate the real stories with confidence.
A spike is often confused with a regular user story. A story delivers working value to users, while a spike delivers information, and any code it produces is usually thrown away rather than shipped. A spike is also different from an MVP: an MVP is a real product released to learn from actual users, while a spike stays inside the team. Spikes should stay rare and small, because a backlog full of them suggests the team is postponing decisions.
Key takeaways
- A spike answers a question or reduces risk; it doesn't ship a feature.
- Every spike has a clear question, a timebox, and an expected output.
- The term comes from Extreme Programming's spike solutions.
- Prototype code from a spike is usually thrown away.
- Spikes help teams estimate stories that were too uncertain to size.
Example
Spike: Can we generate PDF invoices on the server fast enough?
Timebox: 2 days (stop when time is up, even without a final answer)
Questions:
- Can we render a 20-page invoice in under 2 seconds?
- Does the approach work inside our current container setup?
Output:
- A short write-up with a recommendation
- A throwaway prototype (not merged into the main branch)
- Estimates for the follow-up story "Customers can download invoices as PDF"Readers ask
How long should a spike take?
Usually a few hours to a few days, and rarely longer than one sprint. The timebox is fixed in advance, and the team reports what it learned when time runs out, even if the question isn't fully answered.
Do spikes get story points?
Teams differ. Some give spikes a small estimate so they count against sprint capacity, while others simply timebox them without points; what matters is that the time spent is visible in planning.
See also
- User StoryTeams & Process, p. 30A user story is a short, plain-language description of a feature told from the user's point of view, explaining who wants it, what they want, and why.
- Product BacklogTeams & Process, p. 17The product backlog is a single ordered list of everything a team might do to improve a product, such as features, fixes, and technical work.
- Extreme ProgrammingTeams & Process, p. 9Extreme Programming is an Agile method built on engineering practices such as pair programming, test-driven development, and continuous integration.
- Story PointsTeams & Process, p. 28Story points are a unit Agile teams use to estimate the relative size of work items, combining complexity, amount of work, and uncertainty rather than hours.
- MVPTeams & Process, p. 13An MVP is the simplest version of a product that real users can use, built to test a key assumption and learn as much as possible with the least effort.
- SprintTeams & Process, p. 26A sprint is a fixed-length period of one month or less, often two weeks, in which a Scrum team works toward one goal and produces a usable product increment.
- Proof of ConceptTeams & Process, p. 19A proof of concept (PoC) is a small, quick experiment built to show that an idea or technology can work in practice before investing in building it properly.
- TimeboxingTeams & Process, p. 29Timeboxing is setting a fixed maximum time for an activity in advance and stopping when it runs out, keeping work focused and forcing decisions about scope.
Spotted a mistake or something missing on this page?Suggest an edit