Eventos de Scrum. Sprint

7 de julio de 2015

Scrum cuenta con una serie de eventos predefinidos con los que pretende generar regularidad y minimizar la necesidad de reuniones. Todos estos eventos son time-boxed, es decir, que tienen una duración máxima que no debe ser superada. Podrían concluir antes de alcanzar el total de su duración para reducir el gasto, pero nunca después.

Todos los eventos de Scrum son oportunidades para inspeccionar y adaptar dentro de un entorno de transparencia, es por ello que no se debe esperar a la Retrospectiva de Sprint para poner de manifiesto un problema o impedimento, pues podría ser ya demasiado tarde o su solución excesivamente costosa.

Los problemas deben aflorar lo antes posible y su solución llegar tan pronto como sea decidida.

No incluir alguno de estos eventos en nuestra implementación de Scrum podría acarrear una considerable pérdida de transparencia en nuestro proyecto.


El Sprint

No es estrictamente un evento, pues actúa como contenedor para otros eventos pero es el corazón de Scrum alrededor del que todo sucede y es planificado.

Tiene una duración de un mes o menos y nunca debe ser acortado o alargado una vez que ha empezado. Además su duración debe mantenerse, en la medida de lo posible, constante a lo largo de todo el proyecto.

Los Sprints pueden ser de una, dos, tres o cuatro semanas. Scrum desaconseja que su duración supere las cuatro semanas o un mes de calendario, en caso contrario:

  • La definición de lo que está siendo construido podría cambiar.

  • La complejidad prodría aflorar al abordar tareas demasiado grandes en un único Sprint.

  • El riesgo prodría incrementarse hasta quedar fuera de control. Se podría descubrir que lo que se está llevando a cabo no es lo que el cliente espera cuando se haya invertido ya demasiado tiempo en su desarrollo.

Durante el Sprint se sucederán el resto de eventos de Scrum y al finalizar el equipo de desarrollo deberá haber completado un incremento de completa y potencialmente entregable funcionalidad del proyecto.

Completa significa que los desarrollos implementados cumplan con la definición de terminado acordada entre el Product Owner y el Equipo de Desarrollo en la reunión de Planificación de Sprint que tuvo lugar al comienzo del Sprint. Dicha definición recoge el nivel de detalle y acabado que debe cumplir cada elemento del Product Backlog para que pueda aceptarse como terminado.

Potencialmente entregable significa que, si el Product Owner así lo requiriese, la funcionalidad esté lo suficientemente acabada y testada como para ser desplegada en un entorno de Producción inmediatamente después de su aceptación en la reunión de Revisión de Sprint.

Cada Sprint debe contar con una Meta u Objetivo de Sprint.

Dicha meta debe ser una frase lo suficientemente significativa que indique, en términos generales, lo que se espera conseguir al finalizar el Sprint. Esta frase debe dotar de significado a las acciones que el equipo de desarrollo lleve a cabo a lo largo del Sprint, es decir, debe servirle como guía a la hora de decidir si deben o no abordarlas. Además, debe servir como referente al Product Owner para elegir que elementos del Product Backlog son activados para su desarrollo en el Sprint Actual. Por ejemplo, si la meta del Sprint fuera, corregir todos los errores generados y no resueltos durante los últimos cinco Sprints, no tendría mucho sentido incluir elementos de nueva funcionalidad en este Sprint.

Durante el Sprint el Scrum Master velará para que:

  • No se exija al equipo efectuar cambios que puedan poner en peligro la consecución del objetivo de Sprint, es decir, si a mitad de Sprint se pidieran modificaciones al plan original o surgieran problemas que requiriesen alterarlo el Scrum Master será responsable de negociar con el Product Owner para llevar a cabo sólo aquellas que no alejen al equipo de la consecución del objetivo.

    Por ejemplo, la repriorización como urgente de una funcionalidad que no lo era hasta hace un día no debería ser incluída en el plan de Sprint pero la resolución de nuevos bugs que el equipo de QA pudiera localizar mientras prueba las tareas actualmente siendo desarrolladas sí debería ser incluída.

  • Los objetivos de calidad no pueden disminuir. Esto es una verdad universal y, aunque por desgracia no siempre se cumple, debería ser responsabilidad del Scrum Master, Product Owner, equipo de desarrollo, el CEO de la empresa, el cliente y hasta el personal de limpieza de la compañía.

    En el desarrollo de software existe un triángulo que debe ser estrechamente vigilado y cuyo equilibrio se debe favorecer. El triángulo calidad-velocidad-alcance.

    En general tendremos control sobre dos de sus vértices. Si aumenta la calidad y el alcance, cantidad de tareas a desarrollar, disminuirá consecuentemente la velocidad de desarrollo. Si se desea aumentar la velocidad y la calidad, el alcance debería ser reducido. La única forma poder aumentar los tres vértices de forma efectiva suele ser aumentando el coste, pero no se incluye este caso en nuestro ejemplo pues eso supondría alterar el equipo.

    Muchos clientes suelen requerir mantener, o incluso reducir, el tiempo y aumentar el alcance y, en general, no prestan atención a la calidad porque se da por supuesta. Cuando el producto empiece a mostrar debilidades y bugs se enfadarán y manifestarán pérdida de confianza cuando, en realidad, es su responsabilidad.

    Pero… ¿realmente lo es? Es responsabilidad de todos los miembros del equipo Scrum no permitir en ningún caso que descienda la calidad y dar la alarma cada vez que detecten que esto podría suceder o que alguien está intentando deteriorarla, de forma consciente o no, de lo contrario el tiempo necesario para conseguir que el producto se estabilice irá aumentando de forma exponencial.

  • Facilitar que el alcance sea aclarado y renegociado entre el Equipo de Desarrollo y el Product Owner a medida que se aprende más sobre el trabajo a llevar a cabo. Por ejemplo, si el equipo se compromete a entregar diez elementos del Product Backlog en este Sprint y, a según va avanzando en el desarrollo de uno de ellos descubre que, por el motivo razonable que sea, el trabajo necesario para completarlo triplica lo inicialmente estimado, podría renegociar con el Product Owner para que éste decida si es más importante completar dicha funcionalidad o las que le siguen en orden de prioridad dentro del Sprint.

    La decisión final es responsabilidad única del Product Owner y en ningún puede ser decidido unilateralmente por el equipo de desarrollo.

Key Points
En Scrum existen eventos predefinidos para generar regularidad y minimizar la necesidad de reuniones.
Los eventos en Scrum son time-boxed lo que significa que su duración máxima no debe ser superada.
Todos los eventos de Scrum son oportunidades de inspección y adaptación.
Los Sprints en Scrum tienen una duración de cuatro semanas o menos para controlar la complejidad y el riesgo.
Al finalizar el Sprint el Equipo de desarrollo completará un incremento potencialmente entregable.
Cada Sprint tiene un objetivo o meta que da coherencia a las tareas del Sprint.
Durante el Sprint el triángulo calidad-velocidad-alcance debe mantenerse equilibrado.
Durante el Sprint el Equipo de Desarrollo puede negociar el compromiso de Sprint con el Product Owner.