Fundamentos de Scrum Framework: ¿Cómo planificar un Sprint? + Infografía | Autor: Alonso Álvarez | Ilustraciones de Patricia Parreira.

Este artículo forma parte de una serie en la que revisaremos los fundamentos de Scrum complementados con infografías que los explican. 

Puedes consultar los artículos sobre la el Sprint, Planificación, Retrospectiva y Daily.

Diferencia entre Review y Reprostive

El final del Sprint viene marcado por dos eventos: uno se fija en qué hemos conseguido como equipo (la Review o Revisión); otro en cómo lo hemos conseguido (la Retrospectiva). Ambos son momentos para la Inspección y Adaptación, dos de los pilares sobre los que se asienta Scrum. Aunque normalmente se realizan consecutivamente, es importante diferenciar claramente el objetivo y propósito de cada uno de los eventos. 

La Revisión o Review es también conocida como “demo” porque como ya sabemos desde el Manifiesto Ágil, “El producto completado es la media principal de progreso” (originalmente era “software funcional’, pero Scrum se abre a otros campos más allá del software). Así que ha sido habitual convertir este evento en un momento para mostrar resultados, primando el enseñar lo completado sobre explicar qué se ha hecho. 

¿Cómo hacer un Sprint Review en Scrum?

La duración máxima de la Revisión no debería exceder las 4 horas “en un Sprint de un mes”. Al centrarse en la inspección del trabajo realizado, Sprints más cortos requerirán menos tiempo para revisar los logros. 

1. ¿Qué trabajo hemos terminado?

Aunque en la menguante Guía Scrum ya no se indica, debería primarse siempre que sea posible el mostrar el resultado y no sólo explicarlo. Esto, obviamente, va a depender de la naturaleza de la actividad que desarrolle el equipo. Dado que la “demo” o demostración es una actividad habitual en el mundo del software, no debe extrañar que la revisión se centrara tradicionalmente en demostrar el producto funcionando. Scrum nació en el mundo del software y heredó esa idea de la demostración. Hoy en día Scrum se ha abierto a otros campos de actividad, pero la idea de “enseñar” y no sólo contar qué se ha hecho sigue siendo igualmente válida. 

2. Obtener Feedback

Este momento de Inspección y Adaptación es una gran oportunidad para recoger feedback, y no hay feedback más valioso que el obtenido de primera mano. Por ese motivo no solamente asiste el conjunto del equipo Scrum, sino que además se invitan a las partes interesadas o stakeholders a la reunión para que todo el equipo reciba su feedback. 

Los stakeholders son el conjunto de las partes o personas interesadas en mayor o medida en la actividad que realiza el equipo. No todos los stakeholders son iguales: el grado de interés puede ser variable (desde máximo hasta la indiferente e incluso opuestos); lo mismo ocurre con la influencia que puedan tener sobre el trabajo del equipo. Como es natural, el equipo atenderá a los stakeholders en función de esas dos dimensiones y alguna otra que sea relevante para el trabajo. Si hay que invitar a alguien a la revisión, que sean al menos aquellos stakeholders “clave” con mayor interés e influencia: por ejemplo, lo que se suele conocer como “espónsor”, cuyas necesidades se atienden primariamente y que aportan los recursos para el producto; o representantes de equipos con los que haya dependencias cruzadas; o áreas relacionadas con aspectos críticos del producto o servicio (legal, seguridad,…). 

3. Marcar los próximos pasos

Durante el evento, además de presentar el trabajo realizado y los logros del Sprint y recibir feedback, el equipo y los stakeholders analizan los próximos pasos de cara al próximo Sprint. Por ello recalca la Guía que la Revisión es una reunión de trabajo, y no se reduce únicamente a una presentación de resultados. 

Si el equipo recoge métricas (y debería porque es la forma de tomar datos de forma razonada), la Revisión es también un buen momento para revisarlas y compartirlas de forma transparente. Las métricas pueden mostrar el grado de avance y así ayudar a gestionar adecuadamente las expectativas de los stakeholders para anticipar qué podría entregar el equipo en futuros Sprints. Esta es una forma de hacer ajustes en el roadmap, ayudando a tomar decisiones sobre su evolución futura. 

El incremento de producto

El incremento es el resultado de las actividades realizadas durante el Sprint y es objeto de análisis durante la revisión. Puede quedar la sensación de que mientras no concluya el Sprint no hay resultados que entregar, pero nada más lejos de la realidad. Puede haber varios incrementos previos al final de Sprint que se pueden ir entregando a medida que queden disponibles. No hay que supeditar la entrega de valor a la realización del evento de la Revisión.

Al final, el incremento de producto del Sprint se añade a los incrementos previos de manera que “funcionen” juntos (signifique lo que signifique eso dentro del dominio de trabajo del equipo). El incremento se alinea con el Objetivo del Sprint, el Objetivo del Producto y cumple con la Definición de Hecho o DoD (Definition of Done). 

Ese DoD es una lista de las condiciones que debe cumplir el incremento, y es conocido por todo el equipo como una forma de fomentar la transparencia. De hecho, puede haber un DoD para toda la organización, que todos sus equipos deben seguir. Si no existe, puede haber una específica de cada equipo. Si el trabajo realizado no cumple con el DoD (normalmente una checklist elaborada desde el punto de vista de la calidad) no se considera un trabajo terminado y vuelve al backlog. 

Lo que no debe hacer nunca el equipo es presentar como hecho algo que no lo es. Simular un grado de avance que no es real lleva a generar desconfianza en stakeholders y otras figuras del entorno del equipo. Aunque pueda ser muy tentador el agradar mostrando un grado de avance superior al real, ese es el camino más rápido para terminar con la confianza, y recuperarla puede ser un proceso muy largo, y puede que no se consiga nunca. 

Las responsabilidades en la revisión

Las responsabilidades (“accountabilities” en el inglés de la Guía Scrum) participan activamente en la revisión a la que están invitadas.

El o la Product Owner tiene un papel especial pues debe dar feedback sobre al trabajo realizado junto a los stakeholders. Una vez más, no hay que esperar hasta el momento de la revisión para recibir ese feedback: el PO está a disposición del equipo que en cualquier momento puede mostrar el estado del incremento y tomar decisiones al respecto. 

El o la Scrum Master harán lo posible porque el evento sea fluido y cumpla con sus expectativas, como en general con todas las actividades del Sprint. Los desarrolladores se asegurarán de que su trabajo cumpla la Definición de Hecho y participarán activamente en la reunión.  

Además, como hemos dicho, junto al equipo Scrum pueden participar stakeholders del producto o servicio. No forman parte de las figuras básicas de Scrum pero su contribución es imprescindible. En realidad, el equipo no es un ente aislado sino que tiene establecer relaciones fluidas con otras partes de la organización: los distintos stakeholders, otros equipos y áreas con las que haya dependencias, posibles equipos de soporte que proporcionen los medios para el trabajo, los clientes y usuarios, etc. 

Tras la Revisión ya sólo queda un paso para considerar el Sprint completado. Y es un paso fundamental: la Retrospectiva. 

Descargar Infografía completa

¿Quieres conocer más prácticas Scrum?

Te recomendamos la formación “Agile Fundamentals”, un curso de 24h para empezar a aprender los conocimiento y habilidades de Scrum y Kanban, acreditado por ICAgile.

IR AL CURSO Agile fundamentals