Saltar al contenido
Be Agile My Friend

Incremento de Producto: ¿Sprint 0, Technical Sprint, Hardening Sprint?

Uno de los principales problemas de no tener aprendido Scrum y su esencia al 100% es realizar Sprints que no produzcan un incremento de producto. Un sprint debe producir un incremento potencialmente desplegable a producción.

La Guía de Scrum define un Sprint de la siguiente manera: “El corazón de Scrum es el Sprint, es un evento de un mes de máxima duración, donde se crea un incremento de producto, usable y potencialmente liberable a producción”.

Muchos equipos de desarrollo piensan que un primer Sprint, de configuración de entorno de desarrollo, es correcto de realizar. Realmente no es así, no se respeta la naturaleza de Scrum ya que no se entrega ningún incremento de producto.

En este post revisaremos 3 de los principales problemas que tenemos al implementar Sprints sin respetar la naturaleza de Scrum al 100%.

Sprint 0

El Sprint cero es comúnmente llamado al pequeño intervalo de tiempo en el que se crea la visión y una primera versión del Product Backlog, para estimar cuándo se podría lanzar una primera release del producto.

Desde luego esta definición no respeta Scrum y su naturaleza. Es importante tener en cuenta de que es correcto hacer esto con el Product Backlog, el Product Owner debería hacer esto desde el momento 1. ¿Pero es necesario ponerlo dentro de un Sprint, y que forme parte del Sprint Goal?.

Technical Sprint

Este Sprint responde a un intervalo de tiempo en el que se dedica a crear el entorno de desarrollo, la arquitectura de código para tener una guía a la hora de liberar el producto a producción en las siguientes iteraciones.

Este es un caso aún más grave que el anterior, puesto que, además de no entregar ningún incremento de producto, se está dedicando tiempo de un Sprint a generar un entorno de desarrollo que, probablemente, no utilicemos en los primeros Sprints. ¿Por qué trabajar en diseñar una arquitectura para algo que no usaremos en las primeras iteraciones?

La solución a esto es generar la arquitectura de desarrollo dentro del Sprint, pero solo de lo que se ha definido en el Sprint Goal. Esto nos permitirá entregar un incremento de producto, que será cada vez mayor en los siguientes Sprints, con nuestra arquitectura ya definida.

Hardening Sprint

El objetivo de este tipo de Sprint es la de estabilizar el sistema para poder hacer una release de producto.

Es una forma muy extraña de realizar Sprints, en donde, lamentablemente, el equipo de desarrollo pierde el foco de desarrollo de incremento, y se centra en estabilizar el sistema, dedicando una iteración completa a solucionar problemas de lanzamiento de productos.

En casos extremos esto se tiene que realizar si o si, ya que necesitamos una arquitectura de desarrollo estable. Sin embargo, hay que tener en cuenta de que el foco debe estar en entregar incrementos de producto, y si hay algún problema de arquitectura, esto se debe hablar con antelación, por ejemplo en los Daily meetings, y dedicar recursos para solucionar cualquier problema que haya. Perderemos velocidad de desarrollo, pero nunca el foco que es entregar incremento.

Conclusiones

Estos 3 tipos de Sprints son muy comunes dentro de equipos con un nivel de madurez bajo/medio implementando Scrum.
Es recomendable no realizarlos, ya que no respetan la naturaleza de Scrum, recordar que siempre hay que entregar un incremento de producto, es mejor perder velocidad de desarrollo que perder el foco del incremento.