Hace mucho tiempo lanzamos un test sobre la Daily Scrum y parece que el experimento tuvo mucho éxito. En este caso, queremos lanzar uno sobre la Sprint Review, uno de los eventos de Scrum que más confusión suelen tener. Muchos lo llaman Demo, sin embargo, sabemos que es mucho más que eso… Por ello, os proponemos un pequeño test para que respondáis.
En este caso, os proponemos hacerlo en google form, así podemos publicar los resultados en unos días. ¿Te animas?
¿Cuáles has marcado? ¿Sabías que todas las actividades que hemos descrito pertenecen a la Sprint Review? ¡Todas son verdaderas! Te animamos a que leas la Scrum Guide y verás que todos los puntos que hemos descrito pertenecen a la Sprint Review. ¿Realizas estas acciones en tu Sprint Review?
Analizamos cada punto:
Es un evento que reúne a los Interesados con el Equipo Scrum, sin interesados no se podría realizar. Es un evento informal, no es de seguimiento. Tiene una duración de 4 horas máximo para Sprints de 30 días, y normalmente menos para Sprint más cortos.
Los interesados son invitados por el Product Owner.
La Sprint Review, es un evento que debe reunir al Equipo Scrum y a los interesados (invitados por el Product Owner). El Product Owner debería conocer en todo momento el estado del producto, recordemos que es el propietario/dueño del mismo. ¿Cómo puedes ser el dueño de un producto cuyo estado es desconocido?
En este evento tratamos de contarle al mundo (los interesados), cómo está nuestro producto. No buscamos un reporte, buscamos aprender si nuestro producto está teniendo éxito en el mercado. ¿Alguien quiere esto o debemos destinar el resto del dinero a otra cosa?
El Product Owner (y no el Development Team) explicará los elementos terminados del Product Backlog y cuáles no están terminados.
Una vez más, si el Product Owner es el propietario, tendrá que ser quien explique el estado del mismo. Ser dueño no es ser “el que manda”, es poder explicar el estado del producto y tener “control” sobre el mismo. Entendamos que su responsabilidad es maximizar valor para la organización a través del producto. No es buena estrategia esperar a la Sprint Review para que el Product Owner se entere de cómo está el producto.
El Development Team habla de lo que estuvo bien, qué problemas se dieron durante el Sprint y cómo se resolvieron. El Development Team realiza una demostración de los elementos terminados, y responde preguntas sobre el incremento actual.
Hablar sobre los problemas es esencial, no todos los problemas se tratan en la retrospectiva. A la hora de desarrollar software, muchas veces tenemos problemas con elementos fuera del equipo: integraciones, piezas de otros departamentos, resolución de dudas, aprobaciones… Todo esto nos resta efectividad. Hablar de estos problemas es importante para que los interesados entiendan el estado del equipo. Así podemos conseguir que se involucren y nos puedan ayudar a resolver estos problemas.
Además, haremos la famosa “demo”. Hay una parte demostración, cierto, pero la Sprint Review no es una demostración como tal, esto es solo una parte. En mi opinión, la parte demo no debería ser el eje central, es más importante entender el impacto de nuestro producto en el mercado que las funcionalidades concretas que tiene.
El Product Owner comenta el estado actual del Product Backlog.
Si fuera necesario, el Product Owner proyecta posibles fechas de subida en función del progreso que ha llevado el Development Team. El Equipo Scrum y los Interesados colaboran sobre qué hacer a continuación, esta información nos servirá para la Sprint Planning.
Una vez hemos hablado del pasado, toca hablar del futuro. ¿Qué es lo próximo que vamos a hacer? El Product Owner comentará lo que contiene el Product Backlog y las próximas funcionalidades que podemos añadir al producto. De hecho, se puede hablar incluso de fechas de subida esperadas en función del progreso que hemos tenido. Cuidado, proyectar fechas en los primeros Sprints no se recomienda porque tenemos poca información del progreso del equipo.
En este punto es importante no dirigir la conversación hacía “esto es lo que vamos a hacer”, sino hacia “esto es lo que podríamos hacer”. Involucrar a los interesados nos puede ayudar a tener un mejor producto. Recuerda que no es un evento de reporte.
Revisamos el potencial uso del producto y los cambios del mercado, con ello tendremos información de lo más valioso para hacerlo a continuación. Repasamos la línea de tiempo, presupuesto y capacidades para anticipar las próximas entregas y las capacidades del producto.
Este punto es quizás el más diferenciador: contrastamos nuestro producto para saber si está funcionando. ¿Alguien pagaría por esto? ¿Estamos resolviendo el problema que tenemos entre manos? ¿Alguien quiere esto? Digamos que son preguntas de producto, y su función es entender si estamos teniendo éxito o no. También hay que enfrentarlo con cuánto nos está costando, el dinero que nos queda, la rentabilidad, etc. Estamos hablando de entregar valor, no de hacer software.
Actualizamos el Product Backlog y obtenemos los elementos que probablemente entren en el siguiente Sprint.
Por último, con todo lo que hemos aprendido actualizamos el Product Backlog, que será una entrada para la próxima Sprint Planning. Si no actualizamos el Product Backlog, ¿de verdad hemos aprendido?
Os dejamos este test como una checklist para saber si hacéis todos los pasos de la Sprint Review. ¿Cómo las hacéis ahora?
