Definición y OBJETIVO del SPRINT REVIEW

El SPRINT REVIEW (o Revisión del Sprint) es uno de los cinco eventos de Scrum y se realiza al final del Sprint. Durante esta ceremonia se revisa el Incremento de Producto, es decir, lo que se realizó durante el Sprint y se analizan los cambios que tuvo el Product Backlog.

El principal objetivo es obtener feedback de los Stakeholders para inspeccionar y evaluar el producto a fin de ajustar el Product Backlog.

¿Cuál es la DURACIÓN del Sprint Review?

El SPRINT REVIEW tiene un timebox de HASTA cuatro horas para un Sprint de un mes.
Si tenemos Sprints más cortos, la duración de esta ceremonia será adecuadamente más corta.

¿Quiénes participan en el Sprint Review?

A lo largo de la REVISIÓN DEL SPRINT participa todo el Equipo Scrum, es decir, el Product Owner, el Scrum Master y el Equipo de Desarrollo y los Stakeholders (los interesados clave invitados por el Product Owner).
El Scrum Master garantiza que el evento se realice y que los participantes comprendan su finalidad. También ejercerá su rol como facilitador, ayudando a mantener el evento dentro del bloque de tiempo.

Actividades típicas de este evento

  • El Product Owner expone los elementos del Product Backlog que se han “Terminado” (pasaron el DoD) y los que no.
  • El Equipo de Desarrollo realiza una exposición del Incremento de Producto, comenta qué problemas surgieron y de qué manera los afrontaron.
  • El Product Owner habla acerca del Product Backlog en su estado actual y proyecta futuros objetivos y fechas de entrega basadas en esta nueva información.
  • TODOS los participantes debaten en base al análisis de cómo está el mercado y el uso potencial del producto, sobre qué hacer a continuación. De este modo la Sprint Review proporciona información de entrada valiosa para el próximo evento: la Sprint Planning.
  • Se revisa el roadmap de producto, los cambios en el presupuesto y las capacidades de el/los equipo/s.

Salida/output del evento

El resultado de la Sprint Review es un Product Backlog revisado, que define los elementos del Product Backlog posibles para el siguiente Sprint. Eventualmente sea necesario que el Product Backlog reciba un ajuste general para enfocarse en nuevas oportunidades.

Ejemplo de Sprint Review

En el siguiente fragmento de video, podemos observar un buen ejemplo de cómo se realizó una demostración de un incremento de producto.

Fuente: Tesla

Buenas prácticas y antipatrones

Planificar una agenda de interesados

Algunas veces ciertos PBIs construidos durante el Sprint impactan solamente a ciertos interesados.
Para fomentar que dichos interesados asistan regularmente a este evento cuando se los requiera, es muy útil planificar una simple agenda de la reunión sobre el orden que vamos a presentar nuestros PBIs. De esta manera, podremos invitar a ciertos interesados a quedarse solamente el tiempo necesario para obtener su feedback y así fomentar que quieran venir a próximas reuniones sin sentir que perdieron dos o tres horas de reunión cuando solamente se sintieron útiles diez minutos.

No usar Power Point

Con excesiva regularidad, los equipos refuerzan el producto con estructuras de apoyo temporales para que funcione bien para la Review o pasan mucho tiempo tratando de «sorprender» a los Stakeholders ​​con una exposición avanzada. Debemos ser convincentes acá: el producto se destaca por sí solo. El equipo demuestra el producto en un entorno aproximado al de un usuario final, sin ningún «soporte de demostración» especial, y sin ningún accesorio que pueda hacer que el producto se vea mejor de lo que es. El Equipo de Desarrollo no debe pasar más de 30 minutos preparándose específicamente para este evento.
Una buena regla general es: No usar Power Point.

Confianza del Product Owner

Es bueno que el Product Owner adopte una postura de escucha con el Equipo de Desarrollo, en particular con respecto al manejo de la deuda técnica y la calidad del producto. Esto ayuda a reforzar la confianza como valor del equipo.

Foco en el producto

Tenemos que tener en cuenta que esta reunión tiene que ver con el producto. 
Si bien el equipo de desarrollo aprende qué tan bien cumplieron con las expectativas de las partes interesadas durante esta reunión, las discusiones sobre el rendimiento y los procesos del Equipo Scrum se producen en la Retrospectiva de Sprint.

Stakeholders prueban el incremento

Una forma divertida y eficaz de validar el Incremento y obtener feedback sobre los PBIs es hacer que los Stakeholders los inspeccionen de manera práctica. Por ejemplo, una empresa de juegos hace que los jugadores jueguen su juego para obtener comentarios. Si bien esta práctica durante el Sprint Review no quita tener que hacer pruebas de aceptación, a veces pueden reducir la necesidad de pruebas que consumen mucho tiempo. 

No es una reunión de control de estado de proyecto

Hemos visto varias veces equipos que ejecutan una Revisión de Sprint pero en la que no participa ningún Stakeholder que pueda proporcionar feedback útil. En tales casos el Product Owner termina aportando su mirada sobre qué le pareció el avance del Sprint y en qué cosas se podría mejorar.
La Sprint Review es una reunión informal, no una reunión de seguimiento, y la presentación del Incremento de Producto tiene como objetivo principal promover el feedback de todos los interesados clave y estimular la colaboración.