¿Qué es un Spike en Agile?

Un 'spike' es un término que nace en Extreme Programming (XP) y que hoy se usa también en Scrum y Kanban para referirse a una tarea de investigación o experimentación acotada. Sirve para reducir la incertidumbre o adquirir el conocimiento necesario antes de estimar o implementar una historia de usuario del backlog. Cuando el equipo no sabe cómo abordar algo, en lugar de comprometerse a ciegas dedica un spike a investigar y luego planifica con datos reales.

El nombre viene de la analogía con clavar una estaca (un "spike") en el terreno para sondear su profundidad: no construyes nada definitivo, solo recoges la información mínima que te permite decidir con fundamento. Es, por tanto, una herramienta de gestión de riesgo más que de entrega de valor directo.

Estimar trabajo que no se entiende lleva a compromisos poco fiables y a sorpresas a mitad del sprint. La incertidumbre tiene dos caras: la incertidumbre técnica (no sabemos si una solución es viable o cómo se comporta) y la incertidumbre funcional (no sabemos qué necesita realmente el usuario o cómo debería comportarse la interfaz). En ambos casos, forzar una estimación sin investigar convierte el plan en una apuesta.

El spike separa de forma explícita "aprender" de "construir". Al aislar la investigación en una tarea acotada, el equipo evita que un problema sin resolver contamine y bloquee el resto de las historias. También hace visible el coste de aprender: la incertidumbre deja de ser un riesgo oculto y pasa a ser trabajo planificado y medido, algo muy alineado con el pensamiento Lean de eliminar el desperdicio que genera el retrabajo.

Los spikes son acotados en el tiempo, a menudo dentro de la duración de un solo sprint, lo que significa que tienen una duración máxima predefinida. No tienen la intención de entregar un incremento funcional al producto, así que no van a producción ni pasan por un deploy. Su resultado no es código listo para desplegar, sino conocimiento: un prototipo desechable, una prueba de concepto, un boceto de interfaz o una recomendación documentada que permite estimar y planificar las historias de usuario reales con confianza.

El límite de tiempo es la parte más importante de la definición. Un spike sin caja temporal se convierte en una madriguera: el equipo sigue investigando indefinidamente buscando la respuesta perfecta. Al fijar de antemano "dedicamos dos días a esto", se obliga a responder la pregunta concreta dentro de ese margen y, si al terminar la duda persiste, esa misma falta de respuesta ya es información valiosa para decidir el siguiente paso.

No toda historia necesita un spike; abusar de ellos ralentiza el flujo. Conviene crear uno cuando se cumple alguna de estas condiciones:

• El equipo no puede estimar la historia porque desconoce el esfuerzo real que conlleva.
• Hay que evaluar una tecnología, librería o API nueva antes de comprometerse a usarla.
• Existen varias soluciones posibles y hace falta compararlas con datos antes de elegir.
• Los requisitos de negocio están tan poco claros que cualquier estimación sería arbitraria.

Si el equipo ya sabe cómo hacer algo y solo es trabajo grande, no es un spike: es una historia que conviene dividir.

Se usan para evaluar aspectos técnicos como el rendimiento, la viabilidad o el impacto de incorporar una nueva tecnología al proyecto. Ejemplos típicos: probar si una base de datos aguanta el volumen previsto, validar que una integración con un servicio externo es posible, o medir el tiempo de respuesta de un algoritmo. El producto del spike técnico suele ser un prototipo desechable acompañado de una conclusión clara.

Se emplean para entender las interacciones de los usuarios o para prototipar y probar elementos de interfaz para una característica concreta. Aquí la incertidumbre es de producto, no de implementación: qué espera el usuario, qué flujo le resulta natural o qué diseño valida mejor una hipótesis. El resultado puede ser un boceto, un prototipo navegable o las conclusiones de una prueba con usuarios que afinan las historias antes de construirlas.

El equipo tiene en el backlog una historia de usuario para añadir pagos con una pasarela que nunca han integrado. Antes de estimarla, crean un spike de dos días para montar una prueba de concepto contra la API: probar la autenticación, simular un cobro y revisar el manejo de errores. Al terminar saben qué esfuerzo real conlleva, documentan los puntos sensibles (gestión de reembolsos, webhooks de confirmación), ajustan la estimación en el siguiente sprint y evitan llevar trabajo bloqueado a producción.

El prototipo del spike no se reutiliza tal cual: se descarta. Lo que sobrevive es el aprendizaje, que se traduce en una historia bien entendida y estimada.

• Spikes sin caja temporal. Sin un límite claro, la investigación se alarga sin fin. El time-box es innegociable.
• Convertir el prototipo en producción. El código de un spike es exploratorio y suele estar sin pulir; arrastrarlo a producción introduce deuda técnica. El entregable es conocimiento, no ese código.
• Usar spikes para enmascarar trabajo grande. Si la historia se entiende y solo es voluminosa, hay que dividirla, no etiquetarla como investigación.
• No definir la pregunta a responder. Un spike sin un objetivo concreto ("¿podemos integrar esta API en nuestro entorno?") deriva en exploración difusa sin conclusión accionable.
• Acumular demasiados spikes en el sprint. Si la mayoría del backlog necesita investigación, el problema está en el refinamiento previo y en límites de trabajo en curso (WIP limit) mal gestionados.

El spike encaja en el refinamiento del backlog y en la preparación de cada sprint, conecta con la forma de planificar historias de usuario y comparte la filosofía Lean de reducir el desperdicio del retrabajo. Su origen está en Extreme Programming, pero hoy es práctica habitual en cualquier equipo Scrum o Kanban que necesite atacar la incertidumbre antes de comprometerse.