Eventos de Scrum. Revisión de Sprint

27 de julio de 2015
http://es.dreamstime.com/fotos-de-archivo-libres-de-regal%C3%ADas-hombre-con-la-lupa-y-la-peque%C3%B1a-mujer-image39989388

Al final de cada Sprint tiene lugar la reunión de Revisión de Sprint.

La reunión de revisión de Sprint es un evento time-boxed de un máximo de cuatro horas de duración para Sprints de un mes y proporcionalmente menor en Sprints más cortos.

Durante esta reunión se inspeccionan los elementos del Product Backlog incluídos en el Sprint para valorar si cumplen su definición de completado. El Product Owner es el encargado de decidir si un ítem cumple o no con la definición de completado y puede requerir la ayuda del equipo de desarrollo para valorar cuestiones técnicas como, por ejemplo, el nivel de cobertura de tests unitarios del proyecto.

Los elementos del Product Backlog pueden estar completos o no, pero en ningún caso podrán estar parcialmente completos. Aquellos elementos que no hayan sido completamente terminados, o que presenten deficiencias, volverán al Product Backlog para ser estimados y priorizados de nuevo. En la práctica suele ocurrir que la mayoría de elementos no completados en el Sprint que termina sean puestos en la cima de la pila del Sprint que empieza, pues suelen ser tareas bien definidas y a las que en muchas ocasiones sólo les restan unas pocas horas de dedicación, no obstante, esto no se cumple siempre o no nos interesa siempre, es por ello que es conveniente que vuelvan al Backlog y sean replanteadas.

Por ejemplo, volvamos al caso de una historia de usuario que requiere que una aplicación Web sea encapsulada en forma de aplicación híbrida para IOs. Si es la primera vez que el equipo genera una aplicación híbrida la historia contará con un alto grado de complejidad e incertidumbre para el equipo de desarrollo. Las tareas con gran incertidumbre deben ser abordadas las primeras dentro del proyecto, pues descubrir que una tarea no es viable en un punto avanzado del mismo puede llegar a suponer el fracaso de todo él.
Si en la revisión de Sprint se concluye que la tarea no está terminada porque se requiere adaptar los estilos de maquetación para que se visualice correctamente en mobile, lo cual no supone un gran esfuerzo, el Product Owner podría decidir no incluir la tarea en el siguiente Sprint sino re-estimar el trabajo restante y re-priorizarla de forma que se concluya en una etapa más tardía del proyecto en la que el aspecto de la aplicación se encuentre cerrado pues, en otro caso, se correría el riesgo de repetir maquetación cuando la incertidumbre sobre la viabilidad de la tarea, es decir, si la aplicación se podría encapsular como híbrida para IOs ya está resuelta.

Ademas de evaluar las tareas llevadas a cabo en el Sprint que termina el Equipo Scrum y los Stakeholders (cliente y demás implicados) colaboran para decidir que elementos del Product Backlog deben ser incluídos en el siguiente Sprint de forma que se maximice su valor.

El resultado de la reunión es un Product Backlog revisado y re-priorizado que será utilizado como elemento de entrada para la reunión de planificación del siguiente Sprint.

Por otro lado el equipo de desarrollo comparte los problemas y dificultades que se haya podido encontrar durante el desarrollo de las tareas y explica cómo los ha resuelto.

Key Points
Tiene lugar al final de cada Sprint.
Es una reunión time-boxed de un máximo de cuatro horas.
Se analiza cada elemento del Backlog incluído en el Sprint y el Product Owner decide si cumple la definición de completado.
Un elemento del Backlog nunca puede estar parcialmente completado.
Los elementos que no cumplen la definición de completado vuelven al Backlog para ser re-estimados y re-priorizados.
El equipo y los stakeholders deciden qué elementos del Backlog son priorizados para que puedan ser incluídos en el siguiente Sprint.
Al terminar se cuenta con un Product Backlog revisado y re-priorizado.