La presentación de un smartphone de última generación, la inauguración de un nuevo hospital, la apertura de una nueva línea de metro en la ciudad, … son ejemplos de cómo mostramos al público los nuevos productos o servicios que se ponen a su disposición.

En Scrum, la Sprint Review es el momento en el que se muestra el incremento del sprint. Sin embargo, al contrario de lo que muchos piensan, el evento es mucho más que una demo. En él debemos recoger el feedback de los asistentes al ver y/o probar el incremento de producto e incorporarlo al Product Backlog. A continuación te dejamos algunos consejos para sacarle el máximo partido:

Estructura la sesión

En la review aparecen los tres pilares de Scrum: transparencia para mostrar los resultados del Sprint; inspección al obtener el feedback de los asistentes; y adaptación del Product Backlog en función del feedback obtenido. Por ello es importante que dispongas de tiempo suficiente para que todo esto ocurra y que todos los participantes tengan claro qué se espera de ellos en cada momento. Un posible guión que nos ha funcionado en los equipos que acompañamos es:

1. Presentación del objetivo del Sprint
2. Demostración del incremento del Sprint
3. Feedback de los asistentes
4. Alineamiento del Product Backlog

Prepárala con tiempo

La review es el momento donde se acercarán personas importantes para tu producto: usuarios, stakeholders, responsables de otros productos, … Por ello es importante que el equipo dedique tiempo a prepararla, de forma que sea interesante para todos los asistentes. Y sí, es responsabilidad de todo el equipo. Durante la preparación podéis fijar las funcionalidades que se mostrarán, qué personas serán las encargadas de presentar el evento y la demo, quiénes recogerán el feedback de los asistentes, …

Programa el evento al principio del sprint

Las agendas están llenas de reuniones, eventos,… , por lo que es fundamental que avises con tiempo para que puedan asistir a nuestra review. Al iniciar el sprint, revisa que todas las personas interesadas están convocadass. Una buena práctica es tener el evento ya calendarizado para tres o cuatro meses en adelante, de forma que siempre sea el mismo día de la semana y a la misma hora. En el caso en que detectes que el día de la review es festivo o coincide con otro evento y es necesario moverlo, recuerda avisar a todos los asistentes. Para aquellos que no pueden asistir a la review puedes plantearte grabar la sesión y dejar la grabación disponible para que puedan ver lo ocurrido.

Evita el efecto demo

“En mi ordenador funcionaba” o “Justo ahora se acaba de caer el entorno” son algunas de las frases estrella del efecto demo. Asegúrate que el incremento de producto se puede mostrar de forma correcta en la review. Es recomendable realizar un ensayo de las funcionalidades que se van a mostrar y tener preparado un plan alternativo por si ocurre el temido efecto demo: cambiar a otro entorno previo donde mostrar el incremento, imágenes o vídeos de las pruebas, un equipo diferente donde probar, …

Evita los cambios de última hora

No es la primera review que se estropea por intentar cambiar una palabra a última hora. Estos cambios se suelen hacer deprisa y muchas veces se consideran tan menores que no se pasan las pruebas correspondientes. El resultado es que el incremento se rompe y no hay tiempo para solucionarlo. En algunos equipos hemos visto cómo se fija una hora límite para incorporar funcionalidades antes de una review. Las funcionalidades que no estén integradas, se mostrarán en el siguiente sprint.

Recoge feedback durante la sesión

Para adaptar nuestro producto a las necesidades del cliente, necesitamos incorporar el feedback de los incrementos que presentamos en la review. Para ello, te invitamos a que escojas el medio que mejor se adapte a tus reviews. Existen multitud de soluciones, desde formularios impresos, formularios online como Google Forms o Microsoft Forms, hasta aplicaciones móviles cómo Mentimeter. Es importante que recojamos el feedback en la sesión y evitemos dejarlo para después de la sesión, ya que esto nos impediría alinear nuestro Product Backlog con los asistentes al evento.

Bonus track

En uno de los clientes en los que trabajamos, hemos preparado un modelo de presentación dedicando una diapositiva a cada parte del guión, para asegurar que ocurren todas las conversaciones necesarias. Repartimos la presentación por algunos equipos y los resultados han sido sorprendentes:

Un equipo ha encontrado que la mejor manera de preparar la presentación es compartir el documento y completarlo en equipo según terminan de preparar las demostraciones. Antes de la review el equipo se reúne para revisar que el documento esté completado y dan los últimos retoques al guión de la sesión.

Otro equipo ha preferido que sea el Scrum Master la persona que impulsa la creación de la presentación. En este equipo en cada review hay una persona encargada de hacer la demostración, lo que está obligando a que ocurran diferentes conversaciones dentro del equipo para transferir el conocimiento.

Un tercer equipo ha ido probando diferentes versiones de cómo mostrar la información dentro de la presentación, hasta encontrar la forma en la que se sienten más cómodos. Ahora ya no utilizan la presentación, tienen interiorizado el guión y utilizan directamente el software de gestión de producto donde administran el Product Backlog.

El objetivo de la plantilla era asegurar las conversaciones durante el evento, pero con el paso de los sprints, cada equipo ha elegido un camino diferente para lograr el mismo fin. En los tres casos, la Sprint Review ha mejorado sustancialmente. Se ha conseguido que el equipo de desarrollo escuche el feedback directo de los usuarios, e incluso pueden resolver algunas de las dudas que plantean al ver el producto. Además, las conversaciones están mucho más centradas en el incremento de producto que se presenta y en la estrategia a seguir en los siguientes sprints, evitando planes a largo plazo.