▶ ¿Qué es el 【 Sprint Review 】 en Scrum?

¿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.

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. 👇👇👇

Marcelo Garcia

Pase mis últimos 10 años trabajando tanto en start-ups como empresas internacionales con equipos utilizando y escalando Scrum como marco principal e impulsando cambios a nivel cultural alineados con la Agilidad.

Durante los últimos 3 años dicté más de 70 entrenamientos y capacité a más de 1800 personas en Scrum y Agilidad.

Estoy certificado como Registered Scrum Trainer (RST) por Jeff Sutherland, cocreador de Scrum y cuento además cuento con las certificaciones RSM, RPO de Scrum Inc. y CSP-SM, CSP-PO, CSD y CAL de Scrum Alliance.

El Product Owner

por Octavio Levy | Jul 31, 2020 | Reglas de Scrum, Scrum

¿Qué es un Product Owner? El Product Owner es el miembro del equipo Scrum responsable de maximizar el valor del producto entregado por el equipo. El objetivo del Product Owner es lograr que entreguemos el producto "correcto", el producto que quiere el mercado y...