Ceremonias Scrum: Sprint Review

Concepto

La reunión de revisión es la oportunidad para inspeccionar el incremento de producto y decidir los cambios necesarios en el Product Backlog.

Reglas

• Duración máxima de 4 horas en Sprints de 4 semanas. Tiempo proporcional para ciclos más cortos
• Participantes: Scrum Master, dueño de producto y equipo de desarrollo obligatorios. Se puede (y debe) invitar a los grupos interesados (stackholders) que sean necesarios para proveer su opinión (feedback) del incremento

Elementos necesarios

• Sala de reuniones
• Elementos audiovisuales para demostrar el incremento
• Pila de producto (Product Backlog)

Desarrollo

El dueño de producto es responsable de invitar al cliente y a los grupos interesados. Al comienzo de la ceremonia, explica qué elementos han sido finalizados y cuáles no. A continuación, el equipo de desarrollo demuestra el incremento y se le realizan preguntas sobre las funcionalidades y capacidades. Luego, el PO comenta el estado del Backlog y qué se hará en los siguientes sprints. El cliente y los stackholders aportan sus opiniones, y el Product Owner reorganiza la pila en consecuencia. Es también el momento que el cual se actualiza el gráfico de quemado de versiones (Release Burn Down Chart).

Resultado

Luego de la ceremonia obtenemos una pila de producto actualizada y alineada con el negocio. Algunos elementos pueden cambiar su prioridad, otros serán removidos y es posible que surjan nuevas historias o épicas. También, perfilamos los items que se incluirán en las siguientes iteraciones.

Problemas habituales

El inconveniente más frecuente durante la revisión de Sprint es la contrastación del grado de avance del proyecto en relación con un cronograma inicial. La situación deviene entonces en un cuestionamiento sobre las causas del inclumplimiento de la predicción, la verificación de la definición de hecho y la detección de fallos (testing). También, son frecuentes los problemas de conectividad, y la preparación insuficiente de la exposición. Tengamos siempre presente que se trata de una reunión de negocio. Dado que, el objetivo es obtener feedback de aquello que estamos desarrollando, es de suma importancia contar con la presencia de stackholder. Es responsabilidad del dueño de producto hacer la invitación efectiva con la anticipación suficiente, así como realizar las preguntas apropiadas para validar y mejorar el producto que se está construyendo. El Product Owner debe estar enterado de antemano de cuáles historias están finalizadas, o sea, con criterios de aceptación (CA) probados y que cumplen con la DoD (Definition of Done). El incremento es válido cuando es potencialmente entregable al mercado (puesta en producción). Por último, recordemos que el PO expone a los grupos interesados, no el equipo al PO. 

Cuando el origen del problema es la aplicación de falso Scrum, esto es, un desarrollo con un alcance y precio cerrado, al igual que la fecha de finalización, y que además, tiene un cronograma establecido de antemano, no hay solución. Este framework no puede garantizar el cumplimiento de un plan predictivo de meses de duración. En cambio, nos propone un enfoque adaptativo y de asimilación de cambios. Si intentamos desvirtuar la terminología, llamando Sprint a las fases, Scrum Master al jefe de proyecto e historia de usuario a los requerimientos funcionales, acabaremos a menudo en un callejón, culpando al marco de trabajo por nuestro error.

En cambio, si los inconvenientes son con la presentación, es una buena práctica realizar uno o dos ensayos el día anterior, así como disponer de la sala una hora antes y asegurar que los medios audiovisuales y de comunicación funcionen correctamente.

Métricas aplicables

• Velocidad del equipo
• Fiabilidad de la previsión
• Valor de negocio entregado
• Product Burn Up
• Cantidad de historias completadas versus iniciadas

Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial-SinObraDerivada 4.0 Internacional.