Spike es un término agile (viene de eXtreme Programming) algunas veces malinterpretado y muchas veces mal utilizado. En el artículo encontrarás una definición y sus objetivos, fundamental para entenderlo y usarlo solo donde tiene sentido.
¿Qué es un spike?
Un spike es un elemento del backlog de producto que tiene mucha incertidumbre, ya sea técnica o funcional. Ese elemento no podemos planificarlo para el siguiente Sprint, ni siquiera podemos estimarlo. En definitiva, el objetivo fundamental de un spike es dejar una o varias historias Ready, y así ser más previsibles y dar mejores estimaciones cuando planificamos.
Tipos de spike
Si se trata de spikes técnicos nos falta conocer más sobre la tecnología. Por ejemplo, puede ser que no hayamos usado nunca un framework de persistencia, proveedor de medios de pago, o tests automáticos end to end. El spike consistirá seguramente en buscar información por Internet, mirar código y documentación oficial, hacer una pequeña prueba de concepto (PoC), mirar si hay librerías de terceros que ayuden a simplificar, hablar con algún proveedor, etc. El resultado de estos spikes, que se establece al inicio, suele ser una decisión técnica, documentación, un diseño inicial y nuevas tareas técnicas.
En el caso de los spikes funcionales nos falta conocer más sobre los requisitos y/o alcance. Por ejemplo, nos falta saber cómo funcionará un flujo de checkout, saber qué información se incluye en la vista principal de una página de producto, o entender la mejor manera de estructurar un informe de resultados mensuales. Requiere generalmente detallar con el Product Owner, entrevistar a un experto del negocio externo al equipo, colaborar con expertos UX/UI si hay que definir flujos, documentar escenarios/tests, mirar código para ver cómo funciona ahora, etc. El resultado puede ser también decisiones, documentación, diagramas, y nuevas historias.
En cualquier caso, los spikes no se suelen estimar y son timeboxed, es decir, ocupan un tiempo del Sprint, por ejemplo 1 día. En ningún caso se produce un incremento de producto, ya que esto se hará en tareas o historias posteriores.
¿Qué no es un spike?
Un spike no es una excusa para no hacer refinamiento. En cada sprint el equipo dedica algo de tiempo (1-2 horas o incluso más) a hacer refinamiento de las historias del sprint que viene. Los spikes se crean cuando hay tanta incertidumbre que no es posible refinar las historias en este ciclo normal dentro del sprint.
Conclusión
Usa spikes para reducir la incertidumbre, ser más previsible, y evitar así bloqueos en el sprint, prisas, acumular deuda técnica, defraudar a stakeholders, etc. Pero úsalos con moderación, 1-2 por sprint. Mantén un equilibrio para no impactar negativamente los incrementos de producto y el valor de las entregas.
siempre da muy buenos tips y enseña algo de forma práctica y aplicable