Revisión del Sprint
Una ceremonia de Scrum que se lleva a cabo al final de cada Sprint donde el equipo demuestra el incremento funcional a los interesados y recoge retroalimentación. A diferencia de un informe de estado, la Revisión del Sprint es una sesión de trabajo colaborativa: los interesados inspeccionan lo que se ha construido, hacen preguntas e influyen en el backlog del producto según lo que ven.
Guion de facilitación
- 1
Abre reiterando el Objetivo del Sprint y lo que el equipo se comprometió a entregar, luego di con claridad qué está Hecho y qué no, y por qué. Encuadra la sesión: 'Esta es una sesión de trabajo, no una presentación — interrumpan, hagan preguntas y dígannos qué cambiarían.'
5 min - 2
Haz que los desarrolladores demuestren el incremento — cada persona muestra el trabajo que construyó, en el producto real, siguiendo un recorrido de usuario realista en lugar de una lista de funcionalidades. Sin diapositivas, sin maquetas, nada que no esté Hecho.
20 min - 3
Cede los controles: deja que los interesados prueben el producto por sí mismos cuando sea práctico, y captura cada pregunta, reacción y sugerencia de forma visible en un tablero a medida que ocurre. Pregunta directamente a los asistentes callados: '¿Para qué usarías esto? ¿Qué falta para eso?'
10 min - 4
Pasa a la conversación del backlog, liderada por el Product Owner: 'Dado lo que acaban de ver, ¿qué deberíamos priorizar a continuación?' Recorre la parte superior del backlog y ajusta abiertamente — que los elementos suban o bajen frente a los interesados es la revisión funcionando como se pretende.
10 min - 5
Aleja el enfoque brevemente: comparte cualquier cambio en el cronograma, el presupuesto o el mercado desde la última revisión, y da una previsión realista de en qué se centrará probablemente el próximo sprint.
5 min - 6
Cierra releyendo la retroalimentación capturada, confirmando qué elementos entran al Backlog del Producto y cuáles se aparcan conscientemente, y agradece a los interesados de forma específica por las aportaciones que cambiaron algo.
5 min
Consejos
La Revisión del Sprint no es una reunión formal de aprobación: es una conversación. Mantenla colaborativa.
Solo muestra software funcional. Demostrar características incompletas erosiona la confianza.
Invita a usuarios reales, no solo a interesados internos, siempre que sea posible: su retroalimentación es más valiosa.
Limita el tiempo estrictamente: 1 hora por cada semana de duración del Sprint (máx. 4 horas para un Sprint de un mes).
Errores comunes
Convertir la revisión en una presentación ensayada de diapositivas — una presentación pulida invita al aplauso en lugar de a la inspección, y el equipo deja de aprender algo que no supiera ya
Dejar que el Scrum Master o el Product Owner hagan toda la demostración mientras los desarrolladores permanecen en silencio — las personas que construyeron el trabajo responden mejor las preguntas y crecen con el contacto directo
Terminar después de la demostración y saltarse la conversación del backlog — inspección sin adaptación es media revisión, y el ciclo de retroalimentación para el que existe el evento nunca se cierra
No capturar la retroalimentación en ninguna parte — los interesados notan en dos o tres sprints que sus comentarios desaparecen, y dejan de asistir
Variaciones
Revisión del Sprint Remota: utiliza compartir pantalla + un tablero de Miro donde los interesados pueden dejar notas adhesivas mientras ven la demostración. Variante asincrónica: graba una demostración en Loom, recoge retroalimentación escrita a través de un formulario, y luego realiza una sesión de discusión de 30 minutos.
Casos de uso
Cuándo usarlo
Cerrar cada sprint con los interesados cuyas prioridades realmente moldean el backlog del producto — la revisión es el momento integrado del equipo para inspeccionar el incremento juntos
Los interesados siguen llevándose sorpresas en el momento del lanzamiento — las revisiones regulares de software funcional reemplazan las grandes revelaciones con pequeños ajustes de rumbo corregibles
Las prioridades del backlog se discuten desde la opinión y la jerarquía — la retroalimentación recogida mientras los interesados navegan por un incremento real es más difícil de descartar que la especulación de sala de reuniones
Un equipo se ahoga en reuniones de informes de estado — una revisión bien dirigida con una demostración del producto en vivo reemplaza las presentaciones de diapositivas y da a los interesados algo a lo que realmente pueden reaccionar
Cuándo no usarlo
Nada alcanzó el estado de Hecho este sprint — demostrar trabajo a medio terminar erosiona la confianza; mantén una conversación breve y honesta sobre lo que ocurrió y lleva el análisis más profundo a la retrospectiva
Como puerta de aceptación donde los interesados aprueban el trabajo — la aceptación contra la Definición de Hecho ocurre durante el sprint; convertir la revisión en una ceremonia formal de aprobación hace que los equipos ensayen teatro en lugar de invitar a la inspección
Para la discusión interna del proceso del equipo — cómo se sintió el sprint, qué mejorar en la forma de trabajar — esa conversación pertenece a la Retrospectiva del Sprint, sin interesados en la sala
Cuando ningún asistente puede influir en el backlog — una revisión para espectadores pasivos es una demostración, no una inspección; graba un breve video de recorrido en su lugar y reserva la sesión en vivo para las personas cuya retroalimentación cambia lo que se construye
Métodos relacionados
Lecturas adicionales
Preguntas frecuentes
¿Cuánto debe durar una revisión del sprint?▾
Una regla práctica útil es una hora de revisión por cada semana de sprint, con la Guía de Scrum limitándola a cuatro horas para un sprint de un mes. Para los sprints de una y dos semanas que ejecutan la mayoría de los equipos, de 30 a 60 minutos es realista: aproximadamente la mitad para la demostración y la otra mitad para la retroalimentación y la conversación del backlog.
¿Quién debe asistir a la revisión del sprint?▾
Todo el equipo Scrum más los interesados que pueden actuar sobre lo que ven — patrocinadores, usuarios clave y cualquier persona cuya retroalimentación deba moldear el backlog. Funciona desde un puñado de personas hasta alrededor de 30; siempre que sea posible invita a usuarios reales, cuyas reacciones valen más que otra ronda de asentimientos internos.
¿Cuál es la diferencia entre la revisión del sprint y la retrospectiva del sprint?▾
La revisión inspecciona el producto con los interesados — qué se construyó, qué retroalimentación merece, cómo debería verse el backlog a continuación. La retrospectiva inspecciona el proceso dentro del equipo — cómo fue el sprint y qué mejorar en la forma de trabajar. Son eventos separados con audiencias diferentes, y fusionarlos suele matar la franqueza que ambos necesitan.
¿Cómo se hace una revisión del sprint en remoto?▾
Comparte el producto en vivo en pantalla — no diapositivas — y acompáñalo con un tablero compartido donde los interesados dejan retroalimentación en notas adhesivas mientras observan, de modo que los comentarios se capturen sin interrumpir el flujo. Para interesados distribuidos también funciona una variante asincrónica: graba un breve video de demostración, recoge retroalimentación escrita mediante un formulario y luego realiza una discusión en vivo de 30 minutos sobre las respuestas.
¿Qué se debe preparar para una revisión del sprint?▾
Confirma qué elementos cumplen realmente la Definición de Hecho, acuerda quién demuestra qué y ensaya una vez el recorrido de la demostración en un entorno estable para que la sesión no se gaste en depurar errores. Más allá de eso, la preparación debe ser ligera — una revisión sobreproducida es una señal de advertencia de que la inspección se ha convertido en actuación.
Planifica tu próximo taller con IA
Workshop Weaver te ayuda a combinar métodos como Revisión del Sprint en una agenda completa y cronometrada en minutos.
Probar gratisMethod descriptions on Workshop Weaver are original content written by our team, based on established facilitation practices. This method was inspired by work from Scrum Guide.