Facilitación de Sprint Review

Hola!, mis notas de la clase

Estructura de un buen Sprint Review:

1. 🧩 Actividad de Check-in
2. 🎯 Presentar el objetivo del Sprint
3. 📋 Presentar los compromisos del Sprint
4. 🤖 Demostración del Incremento
5. 🧐 Recibimos feedback del incremento
6. 🗯️ Discutimos nuevas iniciativas
7. 🤝 Feedback y cierre.

Nosotros medimos el progreso en función al valor que entregamos .

Facilitación de Sprint Review:
Es necesario que en este evento participen los stakeholders, usuario y cliente final.
1.Actividad check-in o rompe-hielo //presentar a los asistentes el objetivo de la reunión.//
.
2. Presentar objetivo del Sprint: que era eso a lo que e equipo se había comprometido.
.
3. Presentación de los compromisos del Sprint: cuales fueron los compromisos del equipo en la sprint planning anterior.
.
4. Demostración del increment: hacer la inspección del producto que se esta construyendo, mostrar el incremento. //no hay inspección a partir de una presentación o análisis de datos.//
Se mide el progreso en función del valor entregado.
.
5. Feeedback del increment: estar pendientes del lenguaje verbal y no verbal, entender como lo que se hizo le aporta valor.
.
6. Discusión de iniciativas: Preguntar que le gustaría que se le incorporara a ese producto para el futuro, no para prometer sino para entender su visón. // este evento es para presentar a los clientes, no al Poduct Owner, el Product Owner debe tener conocimiento total de lo que se hace, estar involucrado en el equipo como miembro activo.
.
7. Feedback y cierre: Preguntar ¿qué se puede hacer para que la proxima sprint review sea mas eficiente?
.
Una buena practica es que los developers sean quien presenten al cliente el increment

Con el tema de la presentacion:

Ojo con los reporte de QA Automatizado, el valor debe ser la muestra del producto terminado, no la estadistica de los casos de prueba finalizados.

El objetivo de una Sprint Review es la inspección del incremento del producto.

Mostrarle al cliente como va el producto, que el pueda usarlo…

Tomar apuntes del feedback del cliente para añadirlo al backlog

👏 Me encantó la reflexión de que es importante de que el Producto Owner esté siempre con el equipo scrum. Cuando Andrés lo explicó con el “expectativa vs. realidad” se me vinieron a la mente muchos escenarios que he vivido.

Las Review deben ser en ambientes de prueba, en donde el producto este funcional para prueba de uso del usuario. Esto permite identificar que el desarrollo cumple con los requerimientos. Se pueden verificar las HU y sus criterios de aceptación pero en producto funcional. No vídeos, no demos (escenarios felices), no reportes de avance, se muestra el incremento del producto.

Hola, les comparto mis notas:
En el Sprint Review como buena practica es necesario que participen los interesados asi como el usuario. Incluirlos en la actividad del Check-in o rompe hielo.
Además de presentar los objetivos del Sprint revisar los compromisos, así como el incremento del Sprint se debe inspección pero no a través de una presentación o un análisis de datos, esto no aporta.
La Sprint Review debe ser una prueba de uso por parte del usuario, asi como la verificación y validación de los criterios de aceptación de las Historias de Usuario y hacer los feedback correspondientes

Hola a todos.

Les comparto mis aportes de como puedo hacer para llevar la sprint review del equipo del caso de estudio a un espacio mas productivo:

1. Capacitar al equipo sobre el objetivo del evento, los participantes y la estructura del mismo.
2. Garantizar que el PO participe de los daily ya que es fundamental que se entere del progreso a lo largo del sprint y no en la sprint review.
3. Permitir la participación del cliente y stakeholders.
4. Dar claridad al equipo de la información que se debe presentar al cliente y/o stakeholders (cumplimiento de compromisos y demostración práctica del incement) no es necesario llevar información asociada a historias de usuario y puntos de historia.
5. Empoderar a los developers y permitirles presentar a los stakeholders los resultados del sprint.
6. Involucrar a los developers para que compartan sus aportes durante la sprint review.

Saludos
Magda 😉

Uno de los valores de la agilidad es la colaboración con el cliente.