Un Spike es un experimento que habilita un conocimiento dentro de un Scrum Team. Es una práctica añadida a Scrum que, mal entendida, puede provocar grandes problemas. Sin embargo, es muy útil en ciertos equipos donde la incertidumbre es excesiva. ¿Qué es un Spike? ¡Lo analizamos!
La entrega como clave de Scrum
La clave del marco de trabajo Scrum es la entrega. Para ello, cada vez que entregamos, es decir desarrollamos delivery ocurren varias cosas mágicas:
- Cerramos trabajo pendiente
- Validamos que lo que hemos entregado aporta valor
- Mejoramos la relación con el cliente porque recibe valor
- Podemos medir la evolución del producto (software funcionando)
- Podemos evaluar la DOD
- Ganamos visibilidad de mercado al poder inspeccionar en la Sprint Review
Es por ello que todos los elementos de Scram Están orientados a la entrega. Prácticamente todo el marco contiene reglas que facilitan o aseguran que entregamos en periodos inferiores a un mes. Es por ello que no hay elementos como la definition of readyo la toma de requisitos dentro del marco scrum.
¿Para qué sirve un Spike?
¿Qué es un Spike en Scrum?
A pesar de que Scrum pone el foco en el corto plazo y en la entrega continua a veces tenemos que combinarlo con un plan de producto estratégico a largo plazo. Esto significa que debemos invertir parte del tiempo en refinar el Product Backlog para prepararnos para los futuros Sprints que vayamos a acometer. El objetivo de Scrum no es asegurar una fecha pero tampoco podemos ignorarlas y desde luego nos ayuda mucho visualizar el futuro para adelantarnos a dependencias que afecten nuestra entrega futura de valor.
Se dice que el 15% de lo que hacemos es indeterminado. Un equipo puede ser muy bueno pero siempre habrá trabajo, que por diferentes causas, nos cueste entender lo que queremos conseguir. A veces, es una mala definición del problema a resolver, otras veces, es falta de conocimiento técnico o bien falta de conocimiento funcional y otras veces debido a dependencias cuyo impacto desconocemos. Sea como fuere, pueden aparecer elementos futuros que no entendemos bien cómo los van a afectar y que necesitan de estudio por nuestra parte.
Nace así el concepto de Spike, un experimento que realizamos para clarificar un determinado ítem del backlog que nos genera incertidumbre.
¿Cómo se utiliza un Spike en Scrum?
Un Spike es un experimento que realiza un Scrum Team para profundizar en un determinado tema que les genera incertidumbre. Muchos equipos lo usan para poder estimar un item aunque, como ya sabemos, Scrum no obliga a estimar. Los Spikes son items del Backlog especiales. Por un lado, el resultado de un Spike no es una entrega de valor, sino la creación de nuevos items resultado de lo investigado. Por ejemplo, podemos investigar una tecnología y descartarla o, por contra, crear tareas para implementarla en el futuro.
Los Spikes no suelen llevar aparejado una estimación porque precisamente son eso, investigación. ¿cuánto tiempo voy a tardar en aprender esto? ¿cuánto tiempo me va a llevar entender el problema que vamos a resolver? Si supiéramos las respuestas, no necesitaríamos hacer ningún Spike.
Si se necesita estimar, solemos recomendar que el tiempo o los puntos de historia que se adjudiquen sea en forma de inversión: “voy a invertir 3 días en averiguar este asunto, después estudiaremos los siguientes pasos”.
Un Spike puede ser planificado en la Sprint Planning junto al resto de elementos. Generalmente suelen asignarse a una persona o conjunto de ellas que vayan a acometer. Incluso, a veces, tienen una incidencia clara sobre el trabajo del propio Sprint. Una vez, en un equipo, tuvimos que investigar una tecnología para determinar si apostamos por ella para el resto del producto. Dado que era muy relevante, decidimos esperar a que se finalizara el Spike para planificar el resto del Sprint en consecuencia al resultado obtenido.
En la Sprint Review recomiendo que los Spikes se cometen como parte del trabajo. Es muy útil mostrar un diagrama de sectores (Tarta) con los diferentes ítems completados en el Sprint, entre ellos los Spikes.
El lado oscuro de los Spikes en Scrum
Existen equipos que abusan en exceso de los Spikes. De hecho, lo consideran una “fase previa” a cualquier Item de trabajo del Product Backlog. Esta decisión provoca una sensación de “waterfall-por-item” donde primero analizamos el problema (Spike), después desarrollamos y por último las pruebas.
Debemos tener cuidado con estas situaciones porque dificultan nuestra capacidad de entregar. Y, cómo comentamos al principio, la ausencia de entrega tiene muchos inconvenientes para un equipo y más aún un Scrum Team.
Es habitual que cada Item requiera de una reflexión previa y, de hecho, Scrum nos brinda el Refinamiento como el momento adecuado para que la hagamos. Puede ocurrir que haya detalles que no estén claros y, aún así, tengamos que trabajarlos posteriormente. Debemos evitar el microdetalle enfermizo. De hecho, cuando un equipo abusa de Spikes para conseguir muchos detalles suele ser un síntoma de un problema más grave.
Inspección y Adaptación
Aunque utilicemos Spikes, debemos entender que Scrum precisamente se centra en resolver problemas complejos donde, efectivamente, hay incertidumbre. La incertidumbre es lo habitual cuando hablamos de un Scrum Team. Por tanto, aunque a veces es buena idea investigar un determinado asunto, debemos convivir con la incertidumbre como parte habitual del proceso de trabajo.
Precisamente, nadie puede garantizar que en cada entrega el éxito es absoluto y rotundo. El éxito suele ser el resultado de inspeccionar y adaptar continuamente el impacto que nuestras entregas provocan en el mercado. ¡Ahí está la esencia de Scrum!
Y tú, ¿usas Spikes en Scrum?
