Fundamentos de Scrum Framework: ¿Qué es la Review? + Infografía

Fundamentos de Scrum Framework: ¿Qué es la Review? + Infografía

Compartir

Share on email
Share on facebook
Share on twitter
Share on linkedin
Share on pinterest

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 el Sprint, la Planificación y Retrospectiva.

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. 

Fundamentos de Scrum Framework: ¿Qué es la Review? | Ilustración de Patricia Pareira

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.

Fundamentos de Scrum Framework: ¿Qué es la Review? | Ilustración de Patricia Pareira

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.

Fundamentos de Scrum Framework: ¿Qué es la Review? | Ilustración de Patricia Pareira

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. 

¿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.

Forma parte de la comunidad #AlwaysLearning

Sobre el autor

Alonso Álvarez

Alonso Álvarez

Alonso Alvarez, Lead Expert de Netmind en agilidad empresarial, tiene más de 25 años de experiencia y un exitoso historial de aumento de la productividad personal y del equipo a través de métodos ágiles. Su conocimiento abarca los métodos ágiles de Scrum, Kanban, DevOps, SAFe, Management 3.0 y Lean en áreas de ingeniería de software. Ha desempeñado muchos roles en la industria del software, incluidos desarrollador, consultor, control de calidad, gerente de proyectos y gerente de departamento. Como formador, su objetivo es ayudar a los alumnos a adquirir nuevas habilidades y conocimientos; como entrenador y mentor, les ayuda a superar retos y dificultades poniendo en práctica nuevas formas de trabajo y organización. Es un apasionado de la innovación, las previsiones futuras y la filosofía, los marcos y los métodos ágiles en general. Alonso es Scrum Master certificado y experimentado, Product Owner y Agile Coach. Autor de dos libros y varios artículos sobre métodos y prácticas ágiles. La bicicleta de montaña, la naturaleza, el cine, los viajes y la fotografía son sus otras pasiones. ¡Conecta con Alonso en LinkedIn .!
Insights Relacionados

SOLICITAR FORMACIÓN A MEDIDA

Por favor, proporciona la siguiente información para ayudarnos a personalizar la solución.

CONTÁCTANOS

Netmind España
Barcelona +34 933 041 720
Madrid +34 914 427 703

Nos puedes encontrar de:
Lunes – Viernes, 9:00-18:00 (GMT+1)

¡Te ayudamos!
[email protected]

¿Dudas sobre servicios/formaciones?
[email protected]

Solicitar Información