SPRINT REVIEW

1. SPRINT REVIEW
Mostrar el trabajo realizado en ese Sprint (producto funcionando) y
Recibir feedback que permita al equipo orientarse hacia el producto final
requerido por el usuario.
Comprobar que la funcionalidad solicitada se ha desarrollado según los
criterios de aceptación propuestos.
CONSEJOS:
• Fundamental que vaya un cliente / stakeholder
• La review no es una demo
• En la medida de lo posible, que lo testee quien lo va a usar.
SPRINT RETROSPECTIVE
Identificar las fortalezas y las áreas de mejora
Se realiza al final para que el equipo pueda mirar hacia atrás en su trabajo e
identificar elementos que podrían mejorarse. Recolectar información, Generar
ideas y Decidir qué hacer. De esta reunión, se proponen acciones que el
equipo pueda implementar en el próximo Sprint.
Se inspecciona cómo fue el último Sprint con respecto a individuos,
interacciones, procesos, herramientas y su definición de Hecho
Se identifican las acciones de mejora y se incorporan al backlog
CONSEJOS:
 Huir de la retrospectiva “día de la marmota”
 Todas las voces tienen que ser escuchadas
 Conseguir el consenso / consentimiento
1. Preparar el escenario: recordar el objetivo de la reunión, y el tiempo
máximo que puede durar.
2. Recabar datos: analizar el estado de ánimo del equipo, presentar
hechos relevantes que han ocurrido en la iteración, identificar ítems
terminados, no terminados, bloqueos, decisiones relevantes tomadas,
etc.
3. Generar entendimiento: analizar los hechos y responder a las
Preguntas
¿Qué ha pasado?
¿Por qué ha pasado?

2. ¿Cómo lo podemos mejorar?
4. Decidir qué hacer: de todo lo identificado, elegir aquello sobre lo que
queremos trabajar para incorporarlo en la siguiente iteración.
5. Cerrar la retrospectiva: marcar responsables para seguir cada una
de las acciones que hemos elegido. Motivar al equipo agradeciendo el
trabajo, la participación y la transparencia.