¿Qué es el 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, es decir, lo que se realizó durante el Sprint, y se analizan los cambios que tuvo el Product Backlog.

Objetivo del Sprint Review

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

Timebox 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 o Sprint Review participa todo el Equipo Scrum, es decir, el Product Owner, el Scrum Master, los Developers 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.

¿Qué temas deben ser discutidos en el Sprint Review?

• Características “terminadas”
  Todo el equipo Scrum expone los elementos del Product Backlog que se han “Terminado” (pasaron el DoD) y los que no.
• Exposición del Incremento del producto
  Los Developers presentan el Incremento de Producto, comentan qué problemas surgieron y de qué manera los afrontaron.
• Estado actual y proyección del Backlog
  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.
• Debate y análisis para el Sprint Planning
  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.
• Revisión del Release Plan
  Se revisa y actualiza el Release Plan o plan de entregas del producto y los cambios que hayan podido surgir, como cambios en el presupuesto y las capacidades de el/los equipo/s.

Salida/output del Sprint Review

El resultado del Sprint Review, luego de haber inspeccionado y haber recibido feedback sobre el Incremento. es un Product Backlog ajustado, listo para enfocarse en nuevas oportunidades para el siguiente Sprint.

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.

Antipatrones y buenas prácticas para el Sprint Review

• Planificar una agenda de interesados
  Algunas veces ciertos Product Backlog Ítems (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.

Conclusiones

El Sprint Review es un evento clave que nos permite transparentar e inspeccionar nuestro Incremento y adaptar nuestro producto rápidamente hacia nuevas necesidades del mercado y de nuestro contexto.

Y vos, ¿ya estás haciendo Sprint Reviews? ¿recibís feedback de los Stakeholders necesarios? ¿adaptás tu producto en base a la nueva información? Te leo en los comentarios. 👇👇👇