Sprint Review: cómo llevarla a cabo (agenda y ejemplos)

Un sprint review es donde el equipo muestra lo que realmente construyó. Bien ejecutado, es una de las horas más valiosas de un sprint: una conversación real entre las personas que construyeron el producto y las personas que lo usan o lo financian.

¿Qué es un sprint review?

Un sprint review es un evento formal de Scrum que se realiza al final de cada sprint. El equipo inspecciona el incremento (todo lo completado durante el sprint) y colabora con las partes interesadas para adaptar el product backlog según lo que aprenden.

La Guía de Scrum (Schwaber y Sutherland, 2020) lo define como una "sesión de trabajo" en lugar de un informe de estado o una demo de una sola vía. La distinción importa. Las partes interesadas no son una audiencia; son participantes que ayudan al equipo a decidir qué construir a continuación.

El sprint review tiene un timebox máximo de cuatro horas para un sprint de un mes. Los sprints más cortos tienen reviews proporcionalmente más cortos; la mayoría de los equipos con sprints de dos semanas lo mantienen en una o dos horas.

Datos clave

• La Guía de Scrum (2020) especifica un timebox de cuatro horas para un sprint de un mes, reducido proporcionalmente para sprints más cortos.
• El sprint review es uno de los cinco eventos de Scrum: sprint planning, daily scrum, sprint review, sprint retrospective y el sprint mismo.
• Un informe State of Agile de 2023 (Digital.ai) encontró que el 71% de los encuestados usaba Scrum o un híbrido de Scrum, lo que convierte al sprint review en una de las reuniones de retroalimentación estructurada más practicadas en el software.

Un planteamiento útil: el sprint review responde "¿Construimos lo correcto?". La sprint retrospective responde "¿Lo construimos de la forma correcta?".

Sprint review vs sprint retrospective

Estos dos eventos ocurren uno tras otro al final de cada sprint, por lo que los equipos a menudo los confunden. Son conversaciones fundamentalmente distintas.

Para un desglose completo del formato y las preguntas de la retrospectiva, consulte la guía de sprint retrospective.

¿Quién asiste a un sprint review?

La Guía de Scrum enumera los siguientes participantes:

• Equipo Scrum: los desarrolladores que construyeron el incremento, el Product Owner y el Scrum Master
• Partes interesadas: cualquiera que el Product Owner invite, como clientes, usuarios, ejecutivos o patrocinadores del negocio
• Expertos en la materia: opcionalmente, especialistas cuyo aporte es relevante para las decisiones sobre qué construir a continuación

El Product Owner suele invitar a las partes interesadas. El Scrum Master se asegura de que el evento se mantenga productivo y dentro del timebox. Los desarrolladores presentan el incremento y responden preguntas directamente. Esta franqueza es intencional. Las partes interesadas reciben información sin filtrar; los desarrolladores reciben reacciones sin filtrar.

Agenda del sprint review

Un sprint review bien estructurado avanza a través de cinco partes. Aquí una agenda de muestra para un review de 90 minutos (típico para un sprint de dos semanas):

Parte 1: Apertura (10 minutos)

El Product Owner abre recapitulando el objetivo del sprint y enumerando los elementos planeados para el sprint. No se salte esto. Las partes interesadas que no estuvieron en el sprint planning necesitan contexto antes de ver la demo.

Parte 2: Demo del incremento (40 minutos)

Los desarrolladores demuestran el software funcional. Software real, no diapositivas. La demo debe corresponder directamente al objetivo del sprint y mostrar que se cumplen los criterios de aceptación. Cada función debe demostrarse en un escenario realista, no en un recorrido pulido.

Consejo: asigne a cada desarrollador las funciones que construyó. Ellos explican el contexto y recorren la funcionalidad. Esto es más creíble que tener a una sola persona demostrando todo.

Parte 3: Retroalimentación de las partes interesadas (20 minutos)

Este es el núcleo del sprint review. El Product Owner facilita una conversación abierta. Preguntas para provocar retroalimentación útil:

• ¿Esto resuelve el problema que tenía en mente?
• ¿Qué haría esto más útil?
• ¿En qué deberíamos enfocarnos a continuación?
• ¿Falta algo o hay algo incorrecto?

Documente todo. El aporte de las partes interesadas moldea directamente la próxima actualización del backlog.

Parte 4: Revisión del backlog (15 minutos)

El Product Owner recorre el product backlog actualizado. Aquí es donde el aprendizaje del sprint se traduce en trabajo futuro. Surgen nuevos elementos. Las prioridades cambian. El equipo y las partes interesadas se alinean sobre qué es lo más importante a continuación.

Parte 5: Cierre (5 minutos)

Adelante el objetivo del próximo sprint, confirme la fecha del próximo review y agradezca a las partes interesadas. Corto y claro.

Cómo llevar a cabo un sprint review efectivo

Paso 1: Prepare el entorno de demo con anticipación

No espere hasta la mañana del review. Configure un entorno de staging, confirme que las cuentas de demo funcionan y pruebe cualquier integración en vivo el día anterior. Una demo rota desperdicia el tiempo de todos y erosiona la confianza.

Paso 2: Informe a las partes interesadas antes de la reunión

Envíe una breve lectura previa: el objetivo del sprint, qué se va a demostrar y cualquier contexto relevante (un flujo de trabajo de usuario que está mejorando, un error que corrigió). Las partes interesadas dan mejor retroalimentación cuando entienden el punto de partida.

Paso 3: Cíñase al software funcional

Muestre solo lo que está terminado según la Definition of Done. Si algo está completo al 80%, no lo demuestre. Mostrar trabajo incompleto crea confusión y expectativas desalineadas. El incremento es solo lo que cumple el estándar del equipo para "terminado".

Paso 4: Invite a las partes interesadas correctas

Más no siempre es mejor. Invite a personas con poder de decisión o conocimiento directo del usuario. Un grupo enfocado de cinco personas comprometidas genera mejor retroalimentación que una audiencia pasiva de veinte.

Paso 5: Capture la retroalimentación en tiempo real

Asigne a una persona para documentar el aporte de las partes interesadas durante la discusión. Los elementos accionables pasan directamente al backlog antes de que termine la sesión, o como mínimo se marcan para que el Product Owner los procese inmediatamente después.

Paso 6: Termine con un próximo paso claro

Antes de que la sala se vacíe, declare el enfoque probable para el próximo sprint. No tiene que ser definitivo. Pero irse sin ninguna dirección compartida es una oportunidad perdida. El sprint review debería sentirse como el cierre de un capítulo y la apertura de uno nuevo.

Buenas prácticas del sprint review

• Mantenga la demo realista. Use datos reales o escenarios cercanos a la realidad. Las demos artificiales no revelan problemas reales de usabilidad.
• Aplique timebox a cada segmento de demo. Si un equipo tiene cinco elementos para mostrar, asigne tiempo por elemento. Sin estructura, las demos se alargan y la retroalimentación se ve comprimida.
• Rote quién presenta. Que cada desarrollador presente su propio trabajo genera confianza en el equipo y le da a las partes interesadas una imagen más clara del equipo.
• No mezcle temas de retrospectiva. Los problemas de proceso pertenecen a la retro. Si una parte interesada plantea una preocupación de proceso del equipo durante el review, anótela y refiérala a la retro.
• Registre las decisiones clave. ¿Qué aprobaron las partes interesadas? ¿Qué se despriorizó? ¿Qué nuevas solicitudes surgieron? Estas decisiones necesitan un registro documentado.

Errores comunes

Tratar el review como una demo de una sola vía. Si las partes interesadas solo están observando y aplaudiendo, está dejando valor sobre la mesa. El sprint review es una sesión colaborativa, no una representación teatral.

Demostrar funciones que no están terminadas. Mostrar trabajo en progreso como si estuviera completo erosiona la confianza. Si algo no está listo, dígalo. Sáltelo o muéstrelo brevemente con advertencias claras.

Saltarse la discusión del backlog. Los equipos que demuestran y luego se retiran se pierden la parte más importante: qué cambia debido a lo que acaban de aprender. La discusión del backlog es donde el resultado del sprint se convierte en la entrada del siguiente sprint.

Ejecutarlo sin las partes interesadas correctas. Un sprint review solo con miembros internos del equipo es simplemente una sincronización de equipo. El valor viene de las perspectivas externas y la retroalimentación real de los usuarios.

Sin preparación. Las demos improvisadas a menudo fallan o se extienden más de lo debido. Una breve lista de verificación de preparación, revisada el día anterior, previene la mayoría de los desastres del sprint review.

Preguntas frecuentes

¿Qué es un sprint review?

Un sprint review es un evento de Scrum que se realiza al final de cada sprint donde el equipo demuestra el incremento completado a las partes interesadas y recopila retroalimentación para actualizar el product backlog. Es una sesión de trabajo colaborativa, no una presentación formal o un informe de estado.

¿Cuánto debería durar un sprint review?

La Guía de Scrum recomienda un máximo de cuatro horas para un sprint de un mes. Para sprints de dos semanas, la mayoría de los equipos ejecutan reviews de una a dos horas. El timebox se escala con la duración del sprint: sprints más cortos, reviews más cortos.

¿Cuál es la diferencia entre un sprint review y una sprint retrospective?

El sprint review se enfoca en el producto: el equipo muestra lo que construyó y las partes interesadas dan retroalimentación. La sprint retrospective se enfoca en el proceso del equipo: cómo trabajaron juntos y qué mejorar. Ambos ocurren al final del sprint, pero cumplen propósitos distintos y tienen participantes distintos.

¿Quién dirige el sprint review?

El Product Owner típicamente facilita el sprint review, abre la sesión y dirige la discusión del backlog. El Scrum Master se asegura de que el evento se mantenga dentro del timebox y sea productivo. Los desarrolladores presentan el incremento directamente.

¿Qué pasa si no se cumplió el objetivo del sprint?

El equipo demuestra lo que se completó. Los elementos incompletos no se presentan como terminados. La brecha entre lo planeado y lo entregado se convierte en un insumo tanto para la actualización del backlog como para la retrospectiva. La transparencia aquí es más valiosa que intentar maquillar los resultados.

---

El sprint review es uno de los eventos de Scrum más simples de llevar a cabo y uno de los más fáciles de ejecutar mal. Una demo corta y bien preparada con las partes interesadas correctas en la sala convierte cada sprint en un ciclo de retroalimentación real. Y eso es lo que mantiene a los equipos construyendo el producto correcto, no solo construyendo rápido.

Para los demás eventos de Scrum, comience con ceremonias ágiles y el daily standup.