Sprint review: qué es y cómo aplicarlo en tu equipo

La sprint review es uno de los eventos de Scrum y ocurre cerca del final de cada sprint. Según la Guía de Scrum 2020, es el penúltimo evento: después viene la retrospectiva, que es la que cierra el sprint. Su propósito es inspeccionar el resultado del sprint y decidir las adaptaciones que siguen.

Tres palabras clave en esa definición:

• Incremento: el resultado concreto del sprint, trabajo que cumple la definición de hecho y que puede mostrarse funcionando.
• Inspeccionar: revisar lo que se construyó frente al objetivo del sprint y frente al objetivo del producto.
• Adaptar: ajustar el product backlog según lo aprendido y las prioridades del negocio.

La guía la describe como una sesión de trabajo en la que el equipo Scrum y las partes interesadas clave revisan lo logrado y lo que cambió en el entorno, y advierte que conviene evitar limitarla a una presentación. Dura hasta cuatro horas para sprints de un mes y, por lo general, menos para sprints más cortos.

Un detalle que suele confundirse: el equipo puede entregar incrementos a los usuarios durante el sprint, antes de esta reunión. La review inspecciona lo logrado; la entrega puede haber ocurrido antes.

Para qué sirve en la práctica (y por qué muchos equipos lo saltan)

Muchos gerentes tratan la sprint review como un trámite. La comprimen, la cancelan cuando hay presión o la fusionan con otras reuniones. El costo de eso es invisible a corto plazo y muy visible a mediano: el equipo pierde el referente de qué se consideró "terminado" y las partes interesadas se desconectan de la realidad del producto.

La sprint review cumple tres funciones que ninguna otra reunión cubre:

1. Cierre visible. El equipo muestra trabajo real. Eso genera un ritmo de entrega que las actualizaciones en Slack no pueden reemplazar.
2. Retroalimentación temprana. Las partes interesadas ven el incremento antes de que el proyecto avance demasiado en una dirección equivocada.
3. Ajuste del backlog. Lo que se aprendió en el sprint cambia las prioridades de los siguientes. Sin review, el backlog se gestiona con suposiciones viejas.

Cómo distinguir la sprint review de la retrospectiva

Esta confusión es la más frecuente. La diferencia es de foco:

Aspecto	Sprint review	Retrospectiva
Pregunta central	¿Qué construimos?	¿Cómo trabajamos?
Participantes	Equipo Scrum y partes interesadas clave	Equipo Scrum (incluye product owner y Scrum Master)
Foco	El producto y su entorno	Personas, interacciones, procesos y herramientas
Resultado	Product backlog revisado	Mejoras concretas, que pueden entrar al siguiente sprint backlog
Momento	Cerca del final del sprint	Después de la review, cierra el sprint

La sprint review mira hacia afuera: ¿qué valor entregamos y qué cambió alrededor? La retrospectiva mira hacia adentro: ¿cómo podemos mejorar como equipo?

Mezclarlas en una sola reunión suele terminar mal por una razón simple: con las partes interesadas en la sala, al equipo le cuesta hablar con franqueza de sus propios problemas.

Estructura paso a paso para dirigir una sprint review

La Guía de Scrum de 2017 detallaba una agenda; la de 2020 la quitó y deja el formato al equipo. Una estructura práctica, inspirada en aquella agenda, tiene cinco momentos. Este es un ejemplo para un sprint de dos semanas con una review de 60 minutos (la proporción de las cuatro horas para un mes daría hasta dos horas):

Momento	Quién lo lleva	Minutos
Apertura y objetivo del sprint	Product owner	5
Demostración del incremento	Desarrolladores	30
Revisión del product backlog	Product owner con todos	15
Cambios de contexto (mercado, clientes, regulación)	Partes interesadas y product owner	5
Acuerdos y cierre	Product owner	5
Total		60

Los minutos son una referencia; ajústalos a tu equipo.

1. Apertura

El product owner recuerda el objetivo del sprint: qué se buscaba, qué se completó y qué quedó fuera, sin adornos.

2. Demostración del incremento

Los desarrolladores muestran el trabajo terminado, solo lo que cumple la definición de hecho. Las tareas en progreso y los prototipos sin funcionar quedan fuera de la demostración. Las partes interesadas preguntan, prueban y comentan.

3. Revisión del product backlog

El product owner presenta el estado del backlog. ¿Qué cambia a partir de lo que se vio hoy? ¿Qué se agrega, qué se elimina, qué sube o baja de prioridad? Si el equipo usa un burndown o mide velocidad, este es un buen momento para revisar el avance hacia el objetivo del producto.

4. Cambios de contexto

Si hay cambios relevantes (un competidor, un cambio regulatorio, una señal de clientes, un ajuste de presupuesto), este es el momento de compartirlos con el equipo.

5. Acuerdos y cierre

¿Qué cambió en el product backlog? ¿Qué candidatos llegan a la próxima planificación del sprint? La selección definitiva se hace en esa planificación; la review deja el backlog listo para ella. Cierra con las decisiones anotadas y un responsable para cada una.

Errores comunes al dirigir una sprint review

Presentar lo que "casi está listo". Lo que todavía no cumple la definición de hecho queda fuera de la demostración. Mostrarlo crea expectativas falsas y confunde a las partes interesadas sobre el estado real del producto.

Hacer la review sin partes interesadas. Sin las personas que necesitan ver el incremento, la reunión se vuelve una conversación interna del equipo, útil pero distinta. Invitarlas es parte del diseño de la reunión; un mapa de stakeholders ayuda a decidir a quién llamar.

Terminar sin decisiones claras. El product backlog debe quedar revisado al finalizar la reunión. Si los participantes salen sin saber qué cambia, la review no cumplió su función.

Convertirla en un informe de estado. Leer una diapositiva con porcentajes de avance reemplaza la inspección por una narración. Muestra el incremento funcionando y deja que las partes interesadas lo prueben.

Qué necesitas como gerente para que funcione

Tu rol en la sprint review depende de si participas como parte interesada, como facilitador o como líder del área. En cualquier caso, hay tres cosas que puedes hacer para que la reunión valga:

• Asegura que el equipo tenga algo para mostrar. Si llegan a la review sin incremento, el problema es anterior: hay que revisar cómo se planifica y cómo se define "hecho".
• Prepara tus preguntas antes de entrar. Una review donde la parte interesada solo asiente no genera retroalimentación útil. Llega con dos o tres preguntas concretas sobre lo que esperabas ver.
• Cierra el ciclo con el backlog. Si la review termina y el backlog quedó igual, vale la pena preguntarse si la inspección fue real.

Si tu equipo trabaja con story points, la velocidad de los últimos sprints ayuda a proyectar cuándo podrían llegar los ítems que se priorizaron en la review. Y si el equipo tiene Scrum Master, suele ser quien facilita la reunión y cuida que no se pase del tiempo.

En resumen

La sprint review es el evento en el que el equipo Scrum y las partes interesadas inspeccionan el incremento y revisan el product backlog. Va antes de la retrospectiva y tiene un propósito distinto: mirar el producto y su entorno, y decidir qué sigue. Dirigirla bien requiere estructura, disciplina para mostrar solo lo terminado y un cierre con decisiones concretas.