Ir al contenido

Spike

De Scrum Manager BoK
Esta página es una versión traducida de la página Spike. La traducción está completa al 100 %.
⏱ 3 min  ·  📅 2026
A spike is a time-boxed piece of research work with an explicit question, undertaken when the uncertainty is about knowledge rather than scope: it serves to buy the information needed to make a decision or to size the work, not to produce functionality. The term comes from Extreme Programming (spike solution).

When a story cannot be estimated because information is missing, more conversation does not help: what is missing is a piece of data that nobody has. The spike is the answer to that situation. It is a legitimate item in the Product Backlog, but of a different kind from a story, and that is why it is confirmed differently: not with acceptance criteria, but with the answer to its question and with the decision that answer makes it possible to take.

When It Applies

The signal that a spike is needed comes from estimability: if a story cannot be estimated because nobody knows how much it will cost, or even whether it is possible, some investigation is probably needed first. Liz Keogh's complexity scale helps you decide: on the lower rungs ("we've all done this before"), you talk it through and build; on the higher ones ("nobody has ever done this"), you buy information with a spike or an experiment instead of continuing to speculate.

Within story splitting, extracting a spike is one of the legitimate technical splits and one of the five patterns in Mike Cohn's SPIDR (the S). It is also a last resort: a spike for every backlog item is a sign that refinement is not doing its job.

The Two Conditions That Keep It Honest

A spike without the following two becomes open-ended research time:

  1. An explicit question. What you want to find out, phrased so that the answer can be recognized when it appears.
  2. A time limit. How much you are willing to invest in finding it out before deciding with whatever you have.

The outcome of a spike can be a recommendation, a ruled-out option, or a reliable estimate for the story that prompted it. What it never is, is a delivery of user value, and pretending that it is (wrapping it in a story template with a made-up user) shuts down the technical conversation that was actually needed: see Technical story.

Common mistake

Spikes without a question, and one spike per story. Without an explicit question and a time limit, the spike turns into open-ended research with no decision attached. And when every story drags its own spike along, research becomes a toll that hides the fact that refinement is not resolving uncertainty ahead of time. The spike is a last resort, not a routine companion.

Resources

🏦 Skill User storiesState of the art and development guide · Skill Arena

📄 Historias de usuario v.5.0 [User Stories, in Spanish]Free download · Scrum Manager · Jan 2026

📄 Scrum Master en equipos con IA v.1.0 [Scrum Master in Teams with AI, in Spanish]Free download · Scrum Manager

📄 Cómo se crea una historia de usuario [How to Create a User Story, in Spanish]Scrum Manager Blog · Jan 2023

References

  • Beck, Kent. (1999). Extreme Programming Explained. Addison-Wesley.
  • Cohn, Mike. (2004). User Stories Applied. Addison-Wesley.
  • Keogh, Liz. (2012). "Estimating Complexity."

See also

Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.