El Sprint Review
La actividad más evidente en un Sprint Review Meeting es la demostración de la funcionalidad construida en el Sprint anterior. Sin embargo, un buen Sprint Review es mucho más que una simple demostración. Veamos juntos una agenda para una reunión de review.
Crear el entorno adecuado para el review
El Product Owner inicia la reunión del Sprint Review dando la bienvenida a todos los participantes. Es suficiente con que diga algo como: "Gracias a todos por estar aquí."
Si los presentes no se conocen entre sí, el Product Owner puede pedirles que se presenten brevemente. Al inicio de una nueva iniciativa de desarrollo de producto, una ronda de presentaciones es generalmente una buena idea. El Product Owner puede saber que Juan de Marketing es Juan de Marketing; sin embargo, los miembros del equipo pueden no saberlo.
También es buena idea que todos los participantes se presenten brevemente cuando nuevos participantes se unen ocasionalmente a los Sprint Reviews. Después de todo, Juan de Marketing puede que solo asista a los Sprint Reviews de los dos Sprints en los que el equipo trabajó en funcionalidades relacionadas con marketing.
Las presentaciones deben ser realmente breves y directas. "Hola, soy Miguel y soy desarrollador. Trabajé en las funcionalidades del carrito de compras" es casi demasiado. "Hola, soy Miguel y soy desarrollador" sería suficiente en la mayoría de los casos. Sin embargo, una vez que un equipo alcanza cierto tamaño, puede ser bastante útil para los stakeholders escuchar brevemente en qué ha estado trabajando cada persona.
Después de la bienvenida y las presentaciones necesarias al inicio, el Product Owner puede establecer algunas reglas adicionales o anunciar las expectativas para el Sprint Review. Por ejemplo, algunos Product Owners consideran importante señalar que siempre se debe mantener un tono amable durante el Sprint Review. Así que si a alguien no le gusta cómo se implementó una funcionalidad, por supuesto puede decirlo; sin embargo, no debería llamar a la implementación "estúpida". Sí, por supuesto todos sabemos estas cosas, pero a veces es necesario recordarlas.
Dependiendo del número de participantes y muchos otros factores, el Product Owner también puede explicar a los presentes que aunque el review busca feedback sobre las funcionalidades construidas hasta ahora, este no es el momento ni el lugar para rediseñar completamente las funcionalidades.
Una vez que hayas terminado con la introducción y las reglas para el review, es momento de pasar al siguiente punto de la agenda.
¿Qué se demostrará en un review y qué no?
En este punto, muchos equipos comienzan directamente con la demostración. Recomiendo que el Product Owner primero dé una breve visión general de lo que se va a demostrar y lo que no.
Para evitar que el Product Owner simplemente lea una lista de elementos que los participantes no pueden seguir, esto debería mostrarse en un monitor o proyector para que todos lo vean. O imprimir la lista con anticipación para quienes quieran una copia.
Personalmente, me gusta enviar esta información como un documento Word por correo electrónico a todos los posibles participantes del Sprint Review Meeting la noche anterior a la reunión. Esto les da a las personas la oportunidad de ver con antelación lo que se va a demostrar. Basándose en eso, cada uno puede decidir por sí mismo si vale la pena asistir al Sprint Review.
La siguiente tabla muestra la información que considero relevante para cada Product Backlog Item. Sugiero listar los elementos en el orden en que se demuestran. Sin embargo, esto puede cambiarse sobre la marcha según sea necesario.
El primer elemento de la tabla es una descripción del respectivo ítem. Allí se inserta una user story u otra descripción. Luego viene el tamaño de los elementos, generalmente en story points. Después viene el estado de los elementos. Principalmente se trata de si están completados o no. Pero cualquier otra cosa que parezca importante en ese sentido también puede añadirse allí. La última columna indica si el elemento se demostrará o no.
Puede que te preguntes por qué debería haber elementos en la lista que no se van a demostrar. He incluido algunos ejemplos en la tabla anterior. Evidentemente, el elemento que se incluyó en el Sprint pero luego se eliminó no puede demostrarse. También he listado una corrección de bug que solo implica una actualización de un carácter en una pantalla; este elemento tampoco está previsto para la demostración.
Es bastante posible que uno o más participantes pregunten por un elemento que originalmente no estaba previsto para la demo. Si eso sucede, siéntete libre de presentar ese elemento junto con los demás. El objetivo no es evitar mostrar ciertos elementos, sino ser respetuoso con el tiempo de las personas al no mostrarles elementos sobre los que no necesitas feedback.
En la tabla de ejemplo, listé un Product Backlog item que se añadió durante el Sprint. Creo que es útil poder ver qué elementos estaban programados para el Sprint desde el principio y cuáles se añadieron durante el Sprint. Si es más común que se añadan elementos durante el Sprint, puedes considerar agregar una columna a la tabla y anotar allí si los elementos fueron planificados o añadidos posteriormente.
Además, también puedes agregar una columna a la derecha indicando si los elementos fueron aceptados por los participantes de la reunión de review, están listos para el release, o similar. Esto es especialmente útil si estas decisiones son una parte oficial del Sprint Review.
Intenta no dedicar demasiado tiempo a esta parte de la agenda. El objetivo aquí no es obtener feedback sobre los elementos ni hablar sobre por qué un elemento planificado solo se implementó parcialmente. Esta lista es simplemente para presentar el contenido de la reunión. Después de que el Product Owner haya presentado esta lista, pasamos a la parte principal del Sprint Review: la demostración.
Nuevas funcionalidades
Este es el corazón de toda reunión de Sprint Review. Si ya estás realizando Sprint Reviews, es bastante posible que esta sea la única parte de la agenda que realmente llevas a cabo.
En esta parte del Sprint Review, se recorren uno por uno los elementos de la lista que previamente se mostraron a los asistentes. Recuerda que el propósito de una reunión de Sprint Review es obtener feedback.
No hay una regla establecida sobre quién debe hacer la demo. En algunos casos, el Product Owner la hará. Yo siempre sugiero esto cuando participan stakeholders particularmente difíciles en el review. En otros casos, los respectivos miembros del equipo demostrarán los elementos en los que trabajaron ellos mismos. Casi cualquier variación es válida aquí. Simplemente experimenta un poco y descubre qué funciona mejor para tu equipo.
Los elementos más importantes
Este es el corazón de toda reunión de Sprint Review. Si ya estás realizando Sprint Reviews, es bastante posible que esta sea la única parte de la agenda que realmente llevas a cabo.
En esta parte del Sprint Review, se recorren uno por uno los elementos de la lista que previamente se mostraron a los asistentes. Recuerda que el propósito de una reunión de Sprint Review es obtener feedback.
No hay una regla establecida sobre quién debe hacer la demo. En algunos casos, el Product Owner la hará. Yo siempre sugiero esto cuando participan stakeholders particularmente difíciles en el review. En otros casos, los respectivos miembros del equipo demostrarán los elementos en los que trabajaron ellos mismos. Casi cualquier variación es válida aquí. Simplemente experimenta un poco y descubre qué funciona mejor para tu equipo.
Los próximos elementos del Product Backlog
El último punto de la agenda del Sprint Review debería ser una discusión sobre el próximo trabajo en el Product Backlog. Dado que el propósito del Sprint Review es obtener feedback sobre el trabajo del Sprint actual, este suele influir en el trabajo de los Sprints siguientes.
Por ejemplo, si a los stakeholders les gusta mucho el aspecto de las nuevas pantallas, el Product Owner puede querer adaptar rápidamente otras áreas del producto al nuevo diseño. O, al stakeholder puede no gustarle la forma en que se implementaron las funcionalidades. Entonces el siguiente Sprint puede usarse para corregir estos problemas en lugar de pasar a los siguientes elementos (como habría ocurrido sin un Sprint Review).
El Product Owner inicia la discusión presentando los próximos elementos potenciales del Product Backlog. Podría decir algo como: "En la pantalla ven diez elementos que había planificado para el próximo Sprint. Sin embargo, me gustaría añadir el elemento XY, que surgió hoy. Probablemente lo incluiré como elemento n.º 3."
El Product Owner luego pide a los participantes su opinión sobre esta lista. Sin embargo, en mi opinión, el Product Owner no debería priorizar durante el Sprint Review basándose en estos comentarios. Hay varias razones para esto. El Product Owner puede necesitar algo de tiempo para reflexionar sobre lo que se dijo. O quizás el Product Owner quiera obtener estimaciones del equipo sobre los cambios que se solicitaron en el review, etc. Así que el Product Owner recoge opiniones en el Sprint Review y toma las decisiones finales con calma después de la reunión.
El final de cada Review
Simplemente termina la reunión agradeciendo a todos su participación. Además, considera agradecer al equipo en su conjunto por su trabajo en el último Sprint, u ocasionalmente a uno o dos miembros del equipo que tuvieron un desempeño particularmente destacado. Luego recuerda a todos cuándo y dónde se llevará a cabo la próxima reunión de Sprint Review.
Después del Sprint Review
Aunque no sea directamente parte de la agenda del Sprint Review, se debe asegurar que todos los nuevos elementos del Product Backlog también se transfieran a la herramienta del equipo o se escriban en un Post-It y se adjunten al Scrum Board.
