Sprint Review: agenda, quién asiste y cómo dirigirla

El equipo de Lena pasó la mañana del viernes puliendo diapositivas para la Sprint Review. Se conectaron once personas, vieron 25 minutos de capturas del pago como invitado, dijeron "buen trabajo" y se fueron. Tres días después del lanzamiento, la líder de soporte mencionó lo que habría dicho si alguien le hubiera preguntado: los clientes invitados no pueden encontrar su pedido después. (El equipo de Lena es un ejemplo ficticio, no un equipo real).

Seguro ya has estado en esa reunión. Parece ir bien y no cambia nada, porque quienes conocen al cliente nunca tocaron el producto.

Esta guía te da una agenda con tiempos para sprints de una a cuatro semanas, lo que dice la Guía de Scrum (revisada en noviembre de 2026), una invitación para copiar, la comparación entre Sprint Review y retrospectiva, y un registro de una página con lo que se decidió.

¿Qué es una Sprint Review?

Una Sprint Review es el evento de Scrum en el que el equipo y sus principales interesados ven lo que se terminó, conversan sobre lo que cambió alrededor del producto y deciden qué hacer después. Según la Guía de Scrum de 2020, su propósito es inspeccionar el resultado del Sprint y determinar futuras adaptaciones.

Es el penúltimo evento del sprint. Después viene la reunión retrospectiva, y luego la siguiente reunión de sprint planning retoma lo que la revisión haya cambiado.

Agenda de la Sprint Review: tiempos para cualquier duración

Elige tu columna y pega los minutos en la invitación. Estos tiempos son nuestra sugerencia, no una regla de Scrum, y usan unos 30 minutos por semana de sprint, la mitad del máximo de la guía.

¿Quieres las decisiones por escrito sin que nadie tome notas? Pon ParrotNotes sobre la mesa y recibe un resumen y las tareas al detener la grabación. Prueba ParrotNotes gratis.

1. Abrir con el objetivo

El Product Owner enuncia el Sprint Goal, dice si se cumplió y enumera lo que se terminó y lo que no. Da primero las malas noticias.

2. Inspeccionar el trabajo terminado

Muestra el producto funcionando, no diapositivas. Mejor aún, cede el teclado y pídele a un interesado que haga una tarea real mientras los Developers observan. Comparte la lista de elementos la noche anterior, para que la gente llegue con preguntas.

3. Preguntar qué ha cambiado

La guía pide que el grupo revise también qué ha cambiado en su entorno. Así que pregúntales directamente a ventas, soporte y finanzas. Un competidor nuevo o un recorte de presupuesto puede importar más que todo lo que construiste.

4. Revisar el Product Goal

Di en una o dos frases dónde está el producto respecto a su objetivo de largo plazo.

5. Decidir qué sigue

Este es el paso que suele quedarse sin tiempo. Repasa lo que escuchaste y deja que el Product Owner agregue, reordene o quite elementos del backlog. Hoy no necesitas un plan final, solo un backlog que refleje lo que aprendió el grupo. Estimar y dividir los elementos nuevos queda para la siguiente sesión de refinamiento del backlog.

6. Repasar y cerrar

Lee en voz alta los cambios del backlog y sus responsables, y envía el registro ese mismo día.

Lo que dice la Guía de Scrum y lo que no

La guía le dedica a este evento una sección corta y es directa sobre el error más común: la Sprint Review es una sesión de trabajo, y el Scrum Team debe evitar limitarla a una presentación.

Buscamos en el texto en inglés de la guía las palabras que los equipos suelen asociar con esta reunión:

• "Demo" no aparece. "Feedback" tampoco. Una demo puede ser parte de una revisión, pero lo que le interesa a la guía es colaborar en qué hacer después.
• "Sign-off" y "approve" tampoco aparecen. "Accept" solo aparece en frases sobre procesos y productos fuera de límites aceptables. La revisión no es el momento en que el Product Owner acepta el trabajo.
• No es una compuerta de lanzamiento. La guía dice que la Sprint Review nunca debe considerarse una compuerta para entregar valor. Puedes lanzar el tercer día y conversarlo aquí.
• El trabajo sin terminar queda fuera. Según la guía, si un elemento del Product Backlog no cumple la Definition of Done, no se puede lanzar ni presentar en la Sprint Review, y vuelve al Product Backlog. Menciónalo en el paso 1 y no lo muestres en el paso 2.

El tiempo máximo es de cuatro horas para un Sprint de un mes, y sobre los sprints más cortos la guía solo dice que el evento suele ser más corto. Los consejos publicados para sprints más cortos varían. A noviembre de 2026, Atlassian recomienda de 30 minutos a una hora por iteración, LogRocket usa una hora por semana de sprint y Spark Academy calcula 90 minutos para dos semanas. Empieza con poco y agrega tiempo solo si el paso 5 sigue quedándose corto.

Quién asiste a una Sprint Review

Asiste todo el Scrum Team, junto con los principales interesados. La guía no dice quién la dirige ni quién envía la invitación, pero Scrum.org describe a los principales interesados como invitados por el Product Owner, y eso es lo habitual.

¿Quién cuenta como principal? Cualquiera que pueda decirte algo que el equipo no sabe, o que vaya a actuar según lo que se decida. Once personas durante una hora son 11 horas-persona, y nuestra calculadora de costo de reuniones muestra cuánto cuesta eso.

Copia esta invitación:

Asunto: Sprint Review, [fecha], de [inicio] a [fin]: prueba [función]

Hola, [nombre]:

Esta es una sesión de trabajo, no una presentación.

El objetivo era: [Sprint Goal, una frase]
Puedes probar: [2-3 elementos terminados]
Nos gustaría tu opinión sobre: [una pregunta específica para esta persona]

Por favor, trae todo lo que haya cambiado de tu lado: clientes,
competidores, presupuesto, plazos. Enviaré un registro de una página
ese mismo día.

[Product Owner]

Lo que más importa es la pregunta específica. "¿Tu equipo usaría esto mañana?" le da a alguien una razón para venir, y "ver nuestro avance" no.

Sprint Review vs retrospectiva: ¿cuál es la diferencia?

La Sprint Review mira el producto con los interesados. La retrospectiva del sprint mira cómo trabajó el equipo, sin ellos. Ambas ocurren al final del sprint, en ese orden.

Un equipo que habla de lo que salió mal con los interesados mirando puede quedarse callado, así que mantén separadas las dos reuniones. Aquí tienes una prueba rápida para cualquier comentario: ¿cambia lo que construimos o cómo trabajamos?

Nuestra plantilla de retrospectiva es gratis si quieres un tablero para la segunda reunión.

Cómo dirigir una Sprint Review cuando se desvía

Ten listas estas frases:

Sobre esa promesa, la guía dice que quienes quieran cambiar el Product Backlog pueden hacerlo tratando de convencer al Product Owner. Una revisión es donde defiendes tu caso, no donde obtienes una fecha.

Esto también funciona fuera del software. Imagina un equipo de marketing ficticio de cuatro personas que revisa una página de webinar que salió durante el sprint. Una vendedora prueba el formulario en su celular, se queda atascada en el séptimo campo y lo dice. Al terminar la hora, acortar el formulario encabeza la lista del siguiente sprint.

Plantilla de Sprint Review: el registro de una página

La guía no pide una minuta, pero el sprint planning necesita estas respuestas. Copia esto en el documento de tu equipo.

REGISTRO DE SPRINT REVIEW
Equipo:            Sprint:              Fecha:
Facilitador:       Product Owner:       Interesados:

1. SPRINT GOAL (¿cumplido? sí / en parte / no)

2. TERMINADO

3. SIN TERMINAR (vuelve al backlog)

4. QUÉ HA CAMBIADO

5. PRODUCT GOAL: dónde estamos

6. CAMBIOS EN EL BACKLOG
   Elemento | Nuevo, movido o quitado | Responsable

7. PREGUNTAS ABIERTAS
   Pregunta | Quién responde | Para cuándo

Aquí está lleno, con el equipo ficticio de nuestra guía de planificación:

REGISTRO DE SPRINT REVIEW
Equipo: Equipo de checkout    Sprint: 42    Fecha: 20 de noviembre
Facilitador: Lena    Product Owner: Ana
Interesados: Joy (soporte), Ravi (ventas), Mei (finanzas)

1. SPRINT GOAL
   Los clientes recurrentes pueden pagar con una tarjeta guardada.
   Cumplido: sí

2. TERMINADO
   Almacenamiento de tarjetas, selector de tarjeta en el pago,
   migración de tokens de pago, prueba inestable de pago corregida

3. SIN TERMINAR
   Mensajes de error de tarjetas rechazadas

4. QUÉ HA CAMBIADO
   Un competidor lanzó el pago en un toque.
   Las comisiones por tarjeta suben en enero (Mei).

5. PRODUCT GOAL: los clientes recurrentes pagan en menos de un minuto
   Ahora 1 min 40 s con tarjeta guardada, antes 3 min

6. CAMBIOS EN EL BACKLOG
   Flujo de tarjeta vencida | Nuevo, puesto 1 | Ana
   Mensajes de error de tarjetas rechazadas | Movido, puesto 2 | Ana
   Apple Pay | Subió, puesto 3 | Ana

7. PREGUNTAS ABIERTAS
   ¿La comisión de enero cambia el orden de tarjetas en el pago?
   | Mei | 24 de noviembre

La sección 6 pasa directo al siguiente plan. Lleva las preguntas abiertas a tu registro de seguimiento de tareas, y consulta nuestra guía sobre la frecuencia de reuniones para acomodar esta reunión junto a las otras reuniones recurrentes.

¿Conviene grabar la revisión?

Grabar le permite al Product Owner escuchar en lugar de escribir durante los pasos 3 y 5. Pregunta primero, di qué vas a conservar y quién lo verá, y detente si alguien se opone. Las reglas de consentimiento varían según el lugar, y nuestra guía sobre el consentimiento de una parte explica lo básico en Estados Unidos.

ParrotNotes graba en un celular o una Mac en la sala, sin bot de reuniones, y te da una transcripción, un resumen y tareas para pegar en el registro. A noviembre de 2026, las grabaciones pueden durar hasta 3 horas en Pro (US$19.99 al mes, o US$14.99 al mes con pago anual).

El plan gratis permite 30 minutos por grabación y 100 minutos al mes, así que omite los primeros cuatro pasos y graba los pasos 5 y 6. En un sprint de dos semanas son unos 20 minutos, y es donde están las decisiones. Descarga ParrotNotes y pruébalo en tu próxima revisión.

Haz de tu próxima revisión una sesión de trabajo

Una buena Sprint Review te da un balance honesto de lo que está Done, noticias de fuera del equipo y un backlog que refleja ambas cosas. Pon el objetivo y el trabajo sin terminar al principio, cede el teclado en vez de mostrar diapositivas, hazle a cada interesado una pregunta específica y envía una página ese mismo día.

El equipo de Lena dejó las diapositivas para el Sprint 42. Joy, de soporte, tomó el teclado, probó una tarjeta guardada vencida en menos de cuatro minutos y llegó a un callejón sin salida. Ana puso la solución al principio del backlog antes de que terminara la hora, y esta vez nadie se enteró del problema primero por un cliente.