Sprint Review: más allá de la demo

La Sprint Review es el evento de Scrum donde se muestra el resultado del sprint. A ella asisten todas las personas interesadas en ver los últimos avances del producto. Pero este evento no es sólo una demo. Una buena review te ayudará en la estrategia de producto.

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.

También te puede interesar.

Entender a los Equipos Scrum desde las Métricas

En nuestro trabajo diario con los equipos Scrum, es importante entender qué está ocurriendo sprint a sprint, y en qué lugares debemos poner el foco de las acciones de mejora de los equipos. También es importante disponer de datos objetivos, que en las sesiones de retrospectiva o de revisión del proceso, nos ayuden a tomar decisiones basadas en la realidad, y no en sensaciones u opiniones subjetivas.

Ventajas de aplicar el Lead Time en los Equipos Scrum

En ocasiones, cuando arrancamos con los Equipos Scrum, nos encontramos con un par problemas habituales: el tamaño de los PBIs y que trabajan en paralelo en todas los PBIs del sprint. Hoy te traigo una solución que hemos puesto en marcha en algunos Equipos Scrum de nuestros clientes.

El Product Owner: el desconocido y olvidado

Desde hace tiempo tengo la sensación que se desconoce la función de un Product Owner.

Burndown y Burnup para el Scrum Master

Como Scrum Master puedes obtener información muy valiosa analizando estos dos gráficos para entender lo que está ocurriendo en tu equipo.

Por dónde empezar como Product Owner que viene de Tecnología

Estás dando tus primeros pasos como Product Owner, tras haber pasado años diseñando y desarrollando software. Te enfrentas a varios dilemas.

El uso de las Métricas para saber nuestro nivel de Incertidumbre

Scrum nos ayuda a manejar la incertidumbre. Pero ¿cómo sabemos que lo estamos consiguiendo? ¿Qué métricas pueden ayudarnos a confirmar que tenemos bajo control la incertidumbre?

La historia de scrum, su primera implementación

Actualmente Scrum es el marco de trabajo más utilizado para implementar modelos Agile. Hoy os contamos como era su primera versión.

¿Tiene mi equipo Scrum los conocimientos necesarios para construir mi Producto?

Scrum propone que nuestros equipos tengan todos los conocimientos para generar productos que cubran nuestras necesidades. Te traigo hoy una herramienta sencilla para averiguar si tus equipos Scrum son realmente multidisciplinares.

En que punto del proceso consideramos el Producto como Entregable

Escoger dentro de nuestro proceso de generación de producto entregable el punto adecuado, puede ser muy complejo cuando dependemos de terceros.

Cómo convivir con las incidencias en un Equipo Scrum

En los Equipos Scrum que desarrollan nuevo software y mantienen el ya existente, es muy habitual tener que lidiar con incidencias provocadas por el software en producción. Su gestión es complicada ya que interrumpen directamente nuestro plan para el sprint, y al producto ya priorizado en el Product Backlog.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada.

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies