Tareas de investigación o Spikes

La incertidumbre en la entrega de valor representa el día a día en un equipo de scrum. Habrá veces en las que esa incertidumbre será fácil de atajar, por ejemplo, una tarea técnica que un solo miembro del equipo pudiera considerar y decidir durante el tiempo estimado. No obstante otras veces la incertidumbre será demasiado alta, tanto como para desafiar las habilidades del equipo y su capacidad de organización, como por ejemplo investigar una solución software que desconoce técnicamente o evaluar el estado del arte de una tecnología en concreto.

 Una de las herramientas para combatir la incertidumbre son las tareas de investigación o spikes. Heredadas de XP (Extreme programming), una tarea de investigación es una exploración técnica o funcional de una historia que permite descubrir soluciones potenciales que estén a nuestro alcance y suelen implicar recopilar información y/o elaborar pruebas.

Por lo tanto, desde el punto de vista de scrum una tarea de investigación es tiempo empleado sobre algo que es incierto, pero no solo eso sino que es bloqueante para el equipo en cuanto a entendimiento, implicaciones y estimaciones.

Además:

• No genera un incremento de funcionalidad inmediato y de por sí no aporta valor.
• Consume tiempo del sprint, bien para desbloquear una historia en curso o como refinamiento para el siguiente.
• Si no se fija un tiempo (timebox) tiene un riesgo importante para el sprint actual.
• No tiene un objetivo vago y debe esperarse un resultado claro del mismo.
• Una persona del equipo (generalmente una) se encarga de realizarla.

¿Dónde añadimos la tarea de investigación?

En mi opinión, el product backlog no es el mejor sitio para añadir una tarea de investigación. Como mencioné antes un ítem de este tipo no tiene valor directo. Tampoco tiene una estimación, sino un tiempo límite o timebox que evita que la investigación se extienda por encima de lo deseable.

Una tarea de investigación realmente no se hace porque sí, forma parte de otra cosa, otra historia, requerimiento, funcionalidad, etc que se pretende ayudar a solucionar, es decir, es parte del plan de acción del equipo de desarrollo, por lo tanto tiende más a ser una tarea/subtarea del sprint backlog asociada a un ítem del mismo.

Por otro lado, un spike encaja perfectamente como una tarea de refinamiento del product backlog, limitado al 10% como dicta la guía de scrum.

¿Qué sucede si en el sprint planning vemos que una historia necesita de una investigación previa?

Hay que tener en cuenta que el equipo de scrum decide qué hacer en base a lo que sabe y conoce en un momento determinado, ya que eso es parte de ser ágil. El sprint backlog no es algo estático, puede (y debe) cambiar en el momento en el que se descubren nuevas necesidades. Una tarea de investigación puede ser una de ellas.

El equipo de desarrollo no está jamás obligado a incluir una historia en un sprint si no está claro su alcance. Por ello, puede decidir como necesaria una investigación previa y que una historia no está aún lista para incluirse como parte del sprint. Por otro lado puede decidir incorporarla junto con una subtarea de investigación que ‘desbloquee’ el trabajo restante, no hay nada que lo impida, pero cuidado, el sprint goal no debe ponerse en riesgo. En última instancia es siempre decisión del equipo de desarrollo.

También quiero mencionar que, habiendo un riesgo implícito en esta acción, las consecuencias favorables o desfavorables pueden ayudarnos a mejorar en el siguiente sprint. Por ejemplo, la experiencia nos puede ayudar a prevenir que una historia con una subtarea de investigación se prolongue en el tiempo más de lo debido si la realizamos un sprint antes como parte del refinamiento. O por el contrario puede ayudarnos a validar que ciertas historias con pequeñas investigaciones son el modelo que mejor nos funciona para el tipo de trabajo que realizamos.

¿Existe el mal uso de un spike?

Como todo, sí.

Usar las tareas de investigación como una herramienta para crear planes o requerimientos fijos e inamovibles hacen de ellos un mal uso en términos ágiles.

Si somos ágiles no podemos atarnos a ningún plan, porque en el momento mismo en el que el plan se ejecuta el origen ya ha cambiado y por lo tanto una o varias asunciones son erróneas o están desfasadas, dando lugar a resultados obsoletos y de menor valor.