Indice de contenidos
¿Qué es una Sprint Review?
El propósito de la Sprint Review es inspeccionar los resultados del Sprint, y buscar posibles oportunidades para los próximos Sprints, esto pasa por adaptar el Product Backlog. Estas actividades se realizan de una manera colaborativa entre el Scrum Team y los Stakeholders durante esta sesión, que dura unas 4 horas como máximo para Sprints de 4 semanas, evidentemente para Sprints más cortos, Reviews más cortas.
¿Elementos claves a abordar en la Sprint Review en Scrum?
Solo por matizar: la Sprint Review es un evento de negocio y no de seguimiento y control donde se podrían abordar las siguientes cosas:
- Durante este evento el Scrum Team (esto incluye el Product Owner :P) presenta los resultados del Sprint y como están avanzando hacia el Product Goal (que podría ser perfectamente un OKR).
- También hablan sobre los cambios que hay en el mercado o situación interna de la organización que puede afectar a los próximos pasos o objetivos a nivel de producto. Esto podría llevar al equipo a ajustar el Backlog para abordar las futuras oportunidades o opciones.
- Los Desarrolladores discuten lo que fue bien durante el Sprint, qué problemas se encontró, y cómo se resolvieron esos problemas.
- El Product Owner debate sobre el Backlog del Producto en su estado actual. También se habla de las fechas posibles de entrega o la Release Planning (Si, en Scrum se puede hablar de fechas posibles de entrega 😉 ).
- Todos los presentes colaboran sobre qué hacer a continuación, de modo que la Revisión del Sprint proporciona información valiosa para la siguiente Sprint Planning
- Revisión del calendario, el presupuesto y las capacidades potenciales para las próximas versiones previstas de funcionalidad y capacidad del producto.
¿Quién asiste a la Sprint Review?
La pregunta del millón ¿A quién invito? pues no es fácil, para poder gestionar las expectativas de tus Stakeholders, primero debemos de saber cual es el objetivo del Sprint o Sprint Goal y evidentemente el Product Goal, en base al Sprint Goal, podríamos plantearnos las siguientes preguntas:
- ¿Cuáles son los stakeholders clave interesados en el Sprint Goal?
- ¿Cuáles son los stakeholders clave, que con su feedback sobre el resultado de este sprint pueden influir en el orden de la Product Backlog?
- ¿Qué Stakeholders Clave podrían brindarnos un feedback constructivo sobre lo que vamos a producir?
Con responder a estas 3 preguntas simples y básicas podríamos obtener un mapa de posibles Stakeholders para nuestra Sprint Review e invitarles (en los próximos post hablaremos sobre quién son esos Stakeholders como crear un mapa de los mismos y cómo gestionar sus expectativas)
No hay que invitar a la gente por invitarla, si hacemos esto, a la segunda o tercera Review, estaremos el PO y los Developers solos, en el mejor de los casos, en el peor, el Scrum Master con los Dev o solo los Dev 🙁.
¿Cómo facilitar un Sprint Review en modo Bazaar?
Para hacer una buena facilitación de la misma, se debe de abordar primero la parte previa o antes del Sprint Review, durante y después.
¿Qué sucede antes de la sesión de la Sprint Review?
Hay muchas cosas que se deben de hacerse antes de realizar una sesión de Sprint Review en modo Bazaar, aquí van unas ideas:
- El Scrum Team y en especial el Product Owner debe de identificar a aquellas personas adecuadas (Stakeholders) que deben de estar presentes, por ejemplo, personas o equipos de una unidad o departamento que colaboran en el producto, sponsor, personas que tienen dependencias con el producto, clientes internos o externos.
- Enviar una agenda a los posibles participantes, en la agenda podemos tener por ejemplo lo siguiente:
- Próximo objetivo del producto
- Objetivo del Sprint
- Que posibles features se van a ver
- Posibles impactos de estas features y Stands
- Otras actividades que consideres: Release Planning, Roadmap, capacidades, Budgeting, etc.
- Si en presencial asegurarse que exista un espacio cómodo para los Stands, que sea lo más informal posible.
- Hay que asegurarse que los Stands están suficientemente separados para no molestarse unos a otros en caso de Review en presencial
- Si es online, crear salas virtuales para cada Stand/Feature (o grupo de features)
- Asegurate que exista comida, bebida y sobre todo azúcar 😛
- Hay que preparar la sesión pensando en resultados en no en actividades. Un buen feedback se obtiene de algo que está terminado.
- Hay que asegurarse que los asistentes tengan tiempo suficiente para visitar mínimo un Stand/Sala y máximo dos. Así que el control de los Timebox es importante.
- ¿Qué sucede durante la sesión de la Sprint Review?
Como se puede observar antes del evento hay muchas cosas que hacer y preparar. Solo por matizar, los eventos efectivos no suceden por arte de magia, sino se diseñan 😉 . Y durante la sesión no es para menos, sino, es aqui es donde sucede la magia, pero, ¿Que hay que hacer?
- Lo primero que se debe de hacer es empezar cuando toca, no esperar ni hacer esperar a las personas que son respetuosas con el resto. Quizás parezca radical pero de verdad, si esto está sucediendo, es que no valoramos el esfuerzo, la profesionalidad y la responsabilidad que tienen las personas que han acudido a tiempo.
- En pocos minutos rompe el hielo con algún icebreaker, no es necesario hacer juegos ni nada, con hacer una ronda de: ¿Como estamos en una palabra? ¿Qué te gustaría llevar de la sesión? También se puede poner en el chat (en caso de una sesión virtual), hay que ser creativos. Ojo, no hay que forzar a nadie a nada 😉 – Duración: 5 minutos
- En los siguientes minutos el/la PO (podría ser cualquier otra persona del Scrum Team 🙂 ) presenta el objetivo del Sprint y cualquier fecha de release si la hubo. Asegurarse que se hable de lo que se ha terminado a nivel de incremento de Producto. No se debe de caer en la trampa del reporte ni del seguimiento de actividades del equipo de cara a los Stakeholders – Duración: 5 minutos
- El facilitador (podría ser el Scrum Master o cualquier otro miembro de entre los Developers) presenta la agenda del día, reparte post-its y bolis, vela por el TimeBox de las actividades. Es de vital importancia que las personas tengan claro que se busca el feedback para mejorar y seguir optimizando la entrega de valor a nivel de producto. El facilitador podría utilizar un reloj con cuenta atrás (en caso de online se puede utilizar el countdown de miro, mural, etc.) – Duración: 5 minutos
- Un developer presenta en una línea (rápidamente) a los stakeholders que takeaways se pueden llevar de esta feature . Duración: 5 minutos
- Los Stakeholders visitan un Stand y colaboran con el PO y el resto del equipo en inspeccionar el incremento (feature) y recogen feedback – 20 minutos
- El PO (o el facilitador) pregunta a los Stakeholders que aprendizajes se llevaron y que feedback pueden compartir. El equipo en su conjunto (incluido el Scrum Master) colaboran recogiendo dicho feedback, agrupandolo, haciendo partícipes a las personas en el mismo
- Repetir los dos pasos anteriores para el siguiente Stand.
- ¿Un pequeño break? con 5 a 10 minutos serán suficiente
- La Product Owner comparte con el resto un mini-resumen del feedback agrupado además de indicar que hará con dicho feedback : ¿alguno irá al backlog? ¿Alguno al siguiente Sprint? ¿Hay que profundizar en algún punto? – Duración: 15 minutos
- Dar las gracias a los asistentes y dar paso a una conversación informal
- Solo con las personas que se considere, profundizar en más detalle sobre cualquier punto o feedback – Duración: 20 minutos
- Anti-patrones de una Sprint Review
En este pequeño video, comentaremos algunos detalles que nos dicen la guía de Scrum de Scrum.org.
