La Sprint Review es uno de los cinco eventos Scrum, y nos dice si un equipo es maduro en Scrum. Es un evento que tiene muchas variantes, y puede marcar la diferencia entre tener un equipo exitoso o un equipo Scrum que no sea capaz de dar resultados. Vamos a hablar de todas las partes del Sprint Review y de su importancia para garantizar la entrega de valor.
La Sprint Review no es una demo
La Sprint Review es un evento de Scrum que ocurre al finalizar el Sprint. En ella, revisamos el Sprint y el resultado del mismo. El accountable de esta reunión es el Product Owner, por tanto él es el que rinde cuentas de este evento. El Development Team lo acompaña, ya que el Scrum Team al completo va a mostrar su producto ante los stakeholders. Por su lado, el Scrum Master, como responsable de que se haga Scrum, velará por el éxito del evento.
Muchas personas llaman a este evento la demo. Y lo enfocan de manera que el Development Team le presenta al Product Owner el resultado de su trabajo. Tras esto, el Product Owner aprobará o rechazará el resultado del Sprint (como si fuera el Coliseo Romano 👍👎)
La Sprint Review es un ejercicio de inspección y adaptación del incremento del producto y del resultado en el mercado que está teniendo. Por tanto, no es una demo, a pesar de que hagamos una demostración de los elementos finalizados del producto.
En Scrum, la Sprint Review se deben de hacer ocho pasos diferentes y no es obligatorio que se hagan en orden. Además, debemos de recordar que es un evento donde se invita a stakeholders y se busca una conversación en la que todos aprendamos y podamos tomar decisiones para ir en la buena dirección. Este evento es informal, el objetivo es aprender y usar ese aprendizaje para adaptarnos y hacerlo mejor, no buscamos formalidades que nos retrasen.
Primera parte de la Sprint Review
Antes de realizar la Sprint Review debemos de tener una conversación para prepararla. El Product Owner debe saber en todo momento el estado actual de su producto. Para ello, hay Product Owners que les basta con mirar Jira. Hay Product Owner que asisten a la Daily Scrum (pero de oyentes). Hay equipos que durante el Sprint le van mostrando al Product Owner las partes finalizadas para recibir su feedback. Y otros, quedan el día antes de la Sprint Review para prepararla. Todas estas técnicas son válidas, es esencial que el Product Owner sea consciente de lo que se va a presentar en la Sprint Review.
El primer paso es invitar a las personas claves que deben asistir a este evento. Está labor pertenece al Product Owner y será él o ella el que decida quién es interesante que participe. Hay equipos incluso que hacen dos o tres Sprint Review de menor duración con stakeholder diferentes para tener conversaciones dirigidas.
Una vez que comienza el evento, el Product Owner debe explicar aquellos elementos del producto que ya han sido finalizados, esto es, que cumplen con la Definition of Done. Estos elementos junto con los previos de otros spring componen el incremento y por eso te conté inspeccionar el estado actual de nuestros productos.
Le toca el turno al Development Team en la Sprint Review
Muchas veces los equipos Scrum no son entes independientes capaces de generar valor por sí mismos. En las organizaciones suele haber dependencias y retrasos que alterar nuestra capacidad de entregar: impedimentos. En la Sprint Review debemos tener espacio para hablar de todos esos problemas, tenemos a stakeholders que han asistido, y quizás puedan ayudarnos. Está labor recae en el de Development Team. Además, deberán de explicar qué decisiones han tomado para superar esos impedimentos si es que lo han conseguido.
A continuación, haremos una demostración del incremento, es decir, de todos los elementos del Product Backlog que están terminados. Después, respondemos dudas de los stakeholders sobre este incremento. Un consejo, si se puede, dejar a los stakeholders de usar el producto. Cuando usamos algo conseguimos mejor feedback.
El futuro del producto
Otra de las acciones necesarias durante la Sprint Review es hablar del futuro del producto. Para ello, inspeccionamos el Product Backlog y los elementos (PBIs) candidatos para los siguientes Sprints. De esta manera, alineamos expectativas de todos los stakeholders.
El siguiente paso de la Sprint Review es, quizás, una de las más desconocidas. El Product Owner, basándose en el progreso del Development Team, puede prometer posibles fechas de entrega si lo considera necesario. Este paso es opcional y mi consejo es que no se tome ni en los primeros Sprints, y sin consultar con el de Development Team. A la hora de analizar el progreso, es mejor basarse en la cantidad de PBIs que son capaces de hacer por Sprint, que en métricas de estimación como puntos u horas.
Toca analizar el mercado
Por último, llega una de las partes más importantes de la Sprint Review y que demuestra mayor madurez Scrum y capacidad de entrega. Recordemos que nuestro no es hacer software ni construir un producto, sino generar valor. El valor es real cuando se pone delante de unos usuarios y ellos afirman que les gusta o que pagarían por ello.
Durante la Sprint Review hacemos un análisis de mercado en el cual estudiamos el impacto de nuestro incremento con respecto a ese mercado. Tenemos que ser capaces de responder a las preguntas más importantes en un producto: ¿Alguien quiere esto que hemos hecho? ¿Esto resuelve parte del problema que queremos resolver? ¿Alguien pagaría por este producto?
En equipos Scrum poco maduros, la mayoría de preguntas se centran en una fecha de entrega o en la cantidad de software del equipo ha hecho (medido en puntos). Hay equipos que analizan si se ha cumplido el Sprint Goal, que nunca es el objetivo del equipo, el Sprint Goal nos ayuda como guía pero una vez acabado el Sprint no nos interesa.
Para este apartado, es clave que todo el grupo participe. No solo queremos la opinión del propio Scrum Team, sino también de los stakeholders afectados. Si el equipo ha hecho release durante el Sprint podemos. además, analizar los resultados que estemos obteniendo de manera más objetiva. Para los equipos más maduros es mejor analizar el resultado directo que la opinión de los stakeholders.
Cerrando la Sprint Review
Durante toda la Sprint Review, hemos hecho muchas acciones y de ellas hemos aprendido. Con todo ese aprendizaje adaptamos el producto con nuevos items o con modificaciones de los existentes de cara a los próximos Sprints. Es una muy buena práctica tener el Product Backlog abierto para añadir o modificar.
Una práctica que aprendí gracias a la empresa Kelea es tener un tablero durante la sesión con diferentes cuadrantes en los que introducir feedback: cosas que nos han gustado, cosas que mejorar, ideas… de esta manera hacemos transparente el resultado del evento. Tras la Sprint Review analizamos este feedback y trabajamos el Product Backlog para incorporarlo.
Muchos equipos Scrum pueden hacer la misma Sprint Review y haber grandes diferencias entre ellos. No es lo mismo hablar del resultado del Sprint en términos de puntos de historia o de rendimiento del equipo versus equipos que hablan de impacto y de ROI. Recordemos que Scrum es maximizar valor, y la Sprint Review es el momento de comprobar si lo estamos consiguiendo. Los equipos que tienen métricas de negocio normalmente tienden a entregar más valor. No se trata de trabajar mucho, sino de trabajar en la dirección adecuada.
Y tú ¿cómo haces la Sprint Review?
