Spike
Un spike es un trabajo de investigación acotado en tiempo y con una pregunta explícita, que se emprende cuando la incertidumbre es de conocimiento y no de alcance: sirve para comprar la información que permite decidir o dimensionar, no para producir funcionalidad. El término viene de la programación extrema (spike solution).
Cuando una historia no se puede estimar porque falta información, seguir conversando no ayuda: lo que falta es un dato que nadie tiene. El spike es la respuesta a esa situación. Es un elemento legítimo de la pila del producto, pero de una clase distinta a la historia, y por eso se confirma de otra manera: no con criterios de aceptación, sino con la respuesta a su pregunta y con la decisión que esa respuesta permite tomar.
Cuándo procede
La señal de que hace falta un spike la da la estimabilidad: si una historia no es estimable porque nadie sabe cuánto cuesta o si siquiera es posible, probablemente hace falta investigar antes. La escala de complejidad de Liz Keogh ayuda a decidir: en los peldaños bajos («todos lo hemos hecho antes») se conversa y se construye; en los altos («nadie lo ha hecho nunca») se compra información con un spike o un experimento en lugar de seguir especulando.
Dentro de la división de historias, extraer un spike es uno de los cortes técnicos legítimos y uno de los cinco patrones de SPIDR de Mike Cohn (la S). Es, además, un último recurso: un spike por cada elemento del backlog es señal de que el refinamiento no está haciendo su trabajo.
Las dos condiciones que lo hacen honesto
Un spike sin las dos siguientes se convierte en tiempo de investigación indefinida:
- Una pregunta explícita. Qué se quiere saber, formulado de modo que se reconozca la respuesta cuando aparezca.
- Un límite de tiempo. Cuánto se está dispuesto a invertir en averiguarlo antes de decidir con lo que se tenga.
El resultado de un spike puede ser una recomendación, un descarte o una estimación fiable de la historia que lo motivó. Lo que nunca es es una entrega de valor de usuario, y fingir que lo es (envolverlo en plantilla de historia con un usuario inventado) desactiva la conversación técnica que sí hacía falta: véase Historia técnica.
Error frecuente
Spikes sin pregunta y un spike por historia. Sin una pregunta explícita y un límite de tiempo, el spike se convierte en investigación abierta sin decisión asociada. Y cuando cada historia arrastra su spike, la investigación se vuelve un peaje que esconde que el refinamiento no está resolviendo la incertidumbre antes de tiempo. El spike es un último recurso, no un acompañante rutinario.
Recursos
🏦 Skill User storiesState of the art y guía de desarrollo · Skill Arena
📄 Historias de usuario v.5.0Descarga gratuita · Scrum Manager · ene 2026
📄 Scrum Master en equipos con IA v.1.0Descarga gratuita · Scrum Manager
🎙️ Ep. 3: Cómo se crea una historia de usuarioScrum Manager Podcast · Spotify
📄 Cómo se crea una historia de usuarioScrum Manager Blog · ene 2023
🎙️ T2 Ep. 7: 5 características de una buena historia de usuarioScrum Manager Podcast · Spotify
Referencias
- Beck, Kent. (1999). Extreme Programming Explained. Addison-Wesley.
- Cohn, Mike. (2004). User Stories Applied. Addison-Wesley.
- Keogh, Liz. (2012). «Estimating Complexity».
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.