Hola!, mis notas de la clase
Fundamentos del Scrum Master
Bienvenida e introducción al curso
¿Qué hace un Scrum Master?
Scrum desde la perspectiva del Scrum Master
Quiz: Fundamentos del Scrum Master
Modelos adaptativos en Scrum
MAC en producto
MAC en proceso
MAC en progreso
Quiz: Modelos adaptativos en Scrum
Servicios del Scrum Master
Servicio al Product Owner
Servicio al Scrum Team
Servicio a la Organización
Scrum Master como Facilitador
Facilitación de Sprint Planning
Facilitación de la Daily Scrum
Facilitación de Sprint Review
Facilitación de Sprint Retrospective
Recomendaciones
Anti patrones de Scrum
Preguntas frecuentes
¿Cómo certificarse?
Quiz: Recomendaciones
Cierre
¿Qué sigue después?
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Si ya tienes una cuenta,
Facilitación de Sprint Review
12/17Recursos
¿Cómo facilitar una Spring Review efectiva?
Facilitar una Spring Review efectiva puede ser un componente crucial para maximizar el potencial de un equipo Scrum. Aquí te contamos cómo hacerlo de manera exitosa, logrando que todos los participantes se involucren y aporten de manera significativa al proceso.
¿Cuál es la importancia de involucrar a los stakeholders y al cliente?
Una de las premisas fundamentales del desarrollo ágil es la colaboración estrecha entre el equipo Scrum, los stakeholders, y, de manera especial, el cliente y los usuarios finales. La participación activa de estos grupos es esencial, ya que:
- El cliente proporciona una retroalimentación valiosa sobre el producto en construcción, asegurando que se alinee con sus necesidades y expectativas.
- El Product Owner deja de ser solo una figura intermedia y se convierte en parte del equipo integral que se comunica constantemente con el cliente.
- Facilitar la interacción directa entre los desarrolladores y los usuarios finales fomenta un mejor entendimiento de las necesidades reales del usuario.
¿Qué pasos seguir para una Spring Review dinámica?
El objetivo principal de una Spring Review es la inspección del incremento del producto desarrollado. Para garantizar su efectividad, sigue estos pasos:
-
Inicia con un 'check-in': realiza una actividad de rompehielos que capture la atención de todos, tanto stakeholders como el equipo Scrum.
-
Define el objetivo de la reunión: esto puede hacerse dentro de la actividad inicial o como un paso siguiente. Presentar una agenda clarifica expectativas y focaliza la conversación hacia el objetivo principal.
-
Repasa el objetivo del Sprint: asegúrate de que todos los presentes conozcan y recuerden el objetivo del Sprint y los compromisos del equipo de desarrolladores.
-
Facilita la inspección del producto: el cliente debe poder interactuar directamente con el incremento del producto. Evita depender de demos o videos, ya que pueden dar una percepción errónea del progreso real.
-
Recolecta retroalimentación: observa no solo los comentarios verbales, sino también el lenguaje no verbal del cliente. Evalúa cómo el incremento resuelve las necesidades planteadas al inicio y discute posibles mejoras o nuevas funcionalidades.
-
Promueve la colaboración continua con el cliente: la presencia constante del Product Owner en el proceso asegura una colaboración más efectiva que la simple presentación de resultados al final del Sprint.
¿Cómo incorporar las opiniones al proceso de mejora?
Cerrar adecuadamente la Spring Review es tan importante como abrirla. Pide retroalimentación a los clientes y stakeholders sobre cómo hacer más eficiente la próxima iteración. Algunas recomendaciones incluyen:
-
Empoderar a los desarrolladores: permitir que los desarrolladores presenten y discutan los incrementos del producto directamente con los clientes fortalece su conexión con el producto y su motivación personal.
-
Facilitar el conocimiento mutuo: promover un entorno donde stakeholders y desarrolladores se conozcan puede mejorar la comunicación y la comprensión mutua.
¿Cómo mejorar el rendimiento y la colaboración en el equipo Scrum?
La claridad en roles y responsabilidades es fundamental. El Product Owner no debe sorprenderse con los resultados al final del Sprint, sino ser parte activa del proceso de desarrollo. Además:
-
Fortalece la capacidad de reacción del equipo: incorporando dentro del Product Backlog las ideas surgidas en la Spring Review, se facilita la adaptación rápida a las necesidades cambiantes del cliente.
-
Alimenta la motivación y el empoderamiento del equipo: valora y visibiliza el trabajo conjunto. Permitir que cada miembro del equipo reciba reconocimiento fomenta una cultura de trabajo más colaborativa y efectiva.
Siguiendo estas prácticas podrás llevar a cabo Spring Reviews más productivas y aprovechar mejor las interacciones con tus stakeholders y clientes, permitiendo que todos los involucrados aporten al éxito del proyecto. ¡Continúa aprendiendo y mejora tus prácticas de desarrollo ágil!
Aportes 14
Preguntas 5
Ordenar por:
Estructura de un buen Sprint Review:
- 🧩 Actividad de Check-in
- 🎯 Presentar el objetivo del Sprint
- 📋 Presentar los compromisos del Sprint
- 🤖 Demostración del Incremento
- 🧐 Recibimos feedback del incremento
- 🗯️ Discutimos nuevas iniciativas
- 🤝 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
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
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.
👏 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.
Check-in: presentación a los clientes, usuarios, etc
Presentar Objetivo: que haya inspección del producto
presentación de los compromisos: verificar cuales fueron los compromisos del planning
Demostración del Increment: debe ser real, no video, no presentaciones, Se mide el progreso en función del valor entregado
Feedback del Increment: el cliente concluye y nos da su feedback verbal y no verbal
Discución sobre nuevas iniciativas: que le gustaría que hiciera el producto mas adelante, no hacer promesas sino ver sus potenciales necesidades del producto
Antipatron: No debe realizarse la demostración al PO porque este se ausente, el PO debe estar al tanto de lo que se desarrolla y no sorprenderse de lo que se está entregando al final del sprint
Feedback y cierre: preguntar que podemos hacer para que la proxima review sea mas eficiente
Buena práctica: los Team Members son los que deben presentar al cliente el increment
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 comunidad y profesor,
Tengo un par de dudas, supongamos que trabajamos para una compañía tipo SaaS, nos contratan a nosotros para diseñar, crear y desarrollar un producto. Dicho esto, estas son mis dos preguntas:
1\. Cuando hablamos de los stakeholders, quién debería asistir a los sprint reviews? (el CEO, el CRO o que persona sería el asistente ideal?)
2\. El Sprint Review con que periodicidad es sano hacerlas? (semanal, quincenal etc)
“**El propósito de la Daily Scrum es inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el Sprint Backlog según sea necesario, ajustando el trabajo planificado entrante”** *Scrume Guide*
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:
- Capacitar al equipo sobre el objetivo del evento, los participantes y la estructura del mismo.
- 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.
- Permitir la participación del cliente y stakeholders.
- 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.
- Empoderar a los developers y permitirles presentar a los stakeholders los resultados del sprint.
- 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.
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?