Sprint Review y retrospectiva: diferencias y ejemplo

Sprint Review y Retrospectiva: Inspección y Adaptación en Scrum

En el corazón del framework Scrum late un principio fundamental: la mejora continua. Para lograr este objetivo, Scrum define dos eventos críticos al final de cada Sprint que permiten a los equipos inspectar su trabajo y adaptarse accordingly. Estos eventos son la Sprint Review y la Retrospectiva de Sprint.

Aunque a menudo se mencionan juntos, cada uno cumple una función distinta y está dirigido a audiencias diferentes. Comprender esta distinción es esencial para aprovechar al máximo el marco de trabajo ágil.

¿Qué es la Sprint Review?

La Sprint Review es un evento inspectorio donde el Product Owner y el Equipo de Desarrollo colaboran con los stakeholders (partes interesadas) para examinar el incremento completado durante el Sprint. Su propósito principal es obtener retroalimentación sobre el producto y ajustar el Product Backlog según las necesidades del mercado o del cliente.

Características clave de la Sprint Review

• Duración máxima: 4 horas para Sprints de un mes (proporcionalmente menor para Sprints más cortos)
• Participantes: Equipo Scrum completo, stakeholders, clientes y cualquier persona interesada en el producto
• Foco: El producto y su valor de negocio, no el proceso de trabajo
• Formato: Demostración del incremento funcional, discusión sobre próximos pasos

Estructura recomendada para una Sprint Review efectiva

1. Bienvenida y contexto (5-10 minutos): Recordar el objetivo del Sprint y qué se prometió entregar
2. Demostración del incremento (30-60 minutos): Mostrar las funcionalidades completadas de manera práctica
3. Preguntas y retroalimentación (20-30 minutos): Los stakeholders expresan opiniones, dudas y sugerencias
4. Actualización del Backlog (20-30 minutos): El Product Owner incorpora nueva información y ajusta prioridades
5. Discusión sobretimeline (10-15 minutos): Revisar proyecciones y fechas de entrega importantes

"La Sprint Review no es una presentación. Es una conversación colaborativa sobre el producto y su dirección."

¿Qué es la Retrospectiva de Sprint?

La Retrospectiva de Sprint es un evento diseñado para la inspección y adaptación del propio proceso de trabajo del equipo Scrum. A diferencia de la Sprint Review, aquí el foco está en cómo se trabajó, no en qué se entregó.

El marcoerl de la Retrospectiva

La retrospectiva sigue un patrón simple pero poderoso:

1. Inspeccionar: ¿Qué salió bien en el Sprint?
2. Inspeccionar: ¿Qué podría mejorarse?
3. Planificar: ¿Qué acciones concretas tomaremos para mejorar en el próximo Sprint?

Formato clásico: Start, Stop, Continue

Una técnica popular para facilitar retrospectivas es el método Start, Stop, Continue:

• Start: Actividades o prácticas que el equipo debería comenzar a hacer
• Stop: Prácticas que no están funcionando y deben abandonarse
• Continue: Lo que funciona bien y debe mantenerse

Otras técnicas efectivas de retrospectiva

• Mad, Sad, Glad: Explora las emociones del equipo (me frustra, me entristece, me alegra)
• 4 L's: Liked (qué gustó), Learned (qué aprendió), Lacked (qué faltó), Longed for (qué se desea)
• Sailboat: Usando metáfora de un barco: viento (lo que nos impulsa), anclas (lo que nos frena), rocas (riesgos)

Inspección y Adaptación: Los Pilares de Scrum

Los conceptos de inspección y adaptación son fundamentales en Scrum y se manifiestan en múltiples niveles:

• Inspección del producto: A través de la Sprint Review, verificamos si el incremento cumple con los criterios de aceptación
• Inspección del proceso: A través de la Retrospectiva, evaluamos la efectividad de nuestra forma de trabajar
• Adaptación del producto: Modificamos el Product Backlog basándonos en la retroalimentación recibida
• Adaptación del proceso: Implementamos mejoras específicas en nuestra forma de colaborar

Esta ciclo constante de inspección y adaptación es lo que permite a los equipos Scrum mejorar progresivamente y entregar valor de manera creciente Sprint tras Sprint.

Ejemplo Práctico: Sprint Review en Acción

Imaginemos un equipo de desarrollo de una aplicación móvil de fitness que ha trabajado en la función de seguimiento de nutrición durante un Sprint de dos semanas.

Sprint Review - Sprint 7

Objetivo del Sprint: Permitir a los usuarios registrar alimentos y ver resumen nutricional

Incremento presentado:
✓ Registro de alimentos con buscador de base de datos
✓ Vista de resumen diario de calorías y macronutrientes
✓ Historial de comidas de los últimos 7 días

Feedback recibido:
- Los usuarios empresariales solicitan exportar datos a Excel
- Un cliente importante pregunta si se puede integrar con sus dispositivos
- El equipo de marketing necesita capturar estos datos para reportes

Acciones del Product Owner:
- Nueva historia prioritaria: Exportación a CSV/Excel
- Investigación sobre APIs de dispositivos de terceros
- Agregar al Backlog: Dashboard de métricas para marketing

Próximo Sprint objetivo: Notificaciones de recordatorio de comidas

Errores Comunes en Sprint Review y Retrospectiva

Incluso equipos con experiencia cometen errores que reducen la efectividad de estos eventos cruciales. Aquí te presentamos los tres errores más frecuentes:

Error 1: Convertir la Sprint Review en una reunión de status

many equipos caen en el error de presentar diapositivas con gráficos de burndown, porcentajes completados y métricas internas. La Sprint Review no es para el equipo, es para los stakeholders. Deben ver el producto funcionando, no datos sobre el proceso. Si los stakeholders preguntan por métricas, es señal de que no se está demostrando suficiente valor tangible del producto.

Error 2: Abandonar la Retrospectiva sin compromisos tangibles

Es común que las retrospectivas se conviertan en sesiones de queja donde se identifican muchos problemas pero no se define ningún plan de acción concreto. El equipo debe finalizar cada retrospectiva con máximo 2-3 mejoras específicas, asignadas a personas concretas y con fecha de revisión. Sin compromisos tangibles, las buenas intenciones se desvanecen Sprint tras Sprint.

Error 3: No asistir a los eventos o tratarlos como opcionales

Cuando el Product Owner no asiste a la Sprint Review o el Scrum Master permite que las retrospectivas se salten por "urgencias", se rompe el ciclo de mejora del equipo. Estos eventos no son negociables dentro de Scrum. Si el equipo no puede dedicarle el tiempo necesario, significa que hay un problema de planificación más profundo que debe abordarse.

Checklist de Dominio: Sprint Review y Retrospectiva

Utiliza esta lista para evaluar tu nivel de competencia en la facilitación y participación de estos eventos ágiles:

• Comprendo la diferencia entre Sprint Review (producto) y Retrospectiva (proceso)
• Preparo la Sprint Review con una demostración práctica del incremento funcional
• Incluyo a los stakeholders relevantes en la Sprint Review y genero espacio para su retroalimentación
• Actualizo el Product Backlog después de la Sprint Review basándome en el feedback recibido
• Facilito la Retrospectiva utilizando técnicas estructuradas (Start/Stop/Continue, Mad/Sad/Glad, u otras)
• Creo un ambiente seguro donde el equipo pueda expresar abiertamente lo que funciona y lo que no
• Defino máximo 2-3 mejoras concretas al final de cada Retrospectiva
• Asigno responsables y fechas a cada mejora identificada
• Reviso las mejoras del Sprint anterior al inicio de cada nueva Retrospectiva
• No mezclo temas: la Sprint Review no incluye métricas de proceso, la Retrospectiva no incluye demos de producto
• Respeto las duraciones definidas en Scrum: 4 horas máximo para Sprint Review, 3 horas para Retrospectiva en Sprints de un mes
• Documento las decisiones y compromisos tomados en ambos eventos
• Busco mejora incremental: no intento cambiar todo de golpe, sino iterate constantemente

Si puedes marcar todos estos puntos con confianza, tienes un dominio sólido de la inspección y adaptación en Scrum. Recuerda: el valor no está en celebrar lo que salió bien, sino en identificar específicamente qué debe cambiar para que el próximo Sprint sea mejor que el anterior.