Índice
¿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. 👇👇👇
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.
Hola Marcelo
La verdad que esta muy bueno el articulo, sera que me entusiasma mucho todo lo que tenga que con scrum.
Muy clara cada una de las definiciones.
Muchas Gracias
Muchas gracias Claudio por tu comentario. Me motiva a seguir escribiendo. Saludos!
Muy claro! Voy a ponerlo en practica en la proxima sprint review
Muchas gracias Federico! Saludos
Hola.
En la empresa en la que trabajo en las Sprint Reviews, o “Demos”, como nosotros las llamamos, la forma de mostrar el incremento de producto es barriendo los requerimientos por parte del Team, como dice este paper, y la forma de asegurar(nos) de que no quedó nada en el tintero es validando las condiciones de satisfacción de las User Stories asociadas a los requerimientos, más allá de cualquier juego o prueba que cualquier stakeholder quiera hacer.
Tenemos un criteri establecido, según el cual un req no se da por aprobado si no cumple con el 90% de las condiciones de satisfacción. Si no pasa ese umbral o vuelve al backlog para replanificación futura, o se da como “hecho” pero se cargan defectos. El camino que se sigue depende de cuán lejos se estuvo de cumplir con todas las condiciones, del grado de urgencia para esas funcionalidad y de la capacidad del equipo en el corto y largo plazo.
Hola Diana, muchas gracias por tu comentario. Te dejo mis comentarios sobre algunos puntos:
Buenas noches ! entonces el sprint review se realiza al finalizar cada sprint y la retrospectiva al entregar el producto completo?
Buenas noches, la retrospectiva se hace inmediatamente después de la review y se hacen en cada Sprint. Mientras que la review tiene foco en obtener feedback sobre el incremento de producto realizado para adaptar el Product Backlog, la retrospectiva se enfoca en inspeccionar la forma de trabajar del equipo y establecer algún experimento para mejorar el proceso y/o relaciones del equipo.
Excelente definición de review, me has ayudado bastante ha poder aterrizar en conceptos de scrum
Muchísimas gracias Jesus por el comentario, es un placer!
Buen día,
En un proyecto entro a discusión si el sprint dura 2 semanas (10 días hábiles) digamos el sprint 1
– (Opción 1) El Review 1 se hace en el día 10
– (Opción 2) Esperar el día 10 y cerrar el sprint, validar que se termino y luego tomarse un par de días el sprint para preparar el Review 1.
Empezar el sprint 2 el día 11 con el Planning y en paralelo trabajar esa presentación del Review 1 y continuar así con los demás Sprints
¿Cómo miras esto y cual es tu sugerencia?
Opción 1. Es necesario el evento de la Review para obtener feedback sobre el incremento y es el imput principal que sale para poder adaptar nuestro backlog para la planning del siguiente Sprint.