Agenda de la sprint review para tomar decisiones sobre el backlog

Si tu sprint review se ha convertido en un pase de diapositivas unidireccional en el que el Product Owner va pasando capturas de pantalla mientras los stakeholders revisan en silencio su correo, lo que tienes es una actualización de estado a la que cada vez asiste menos gente. El patrón es tan predecible que la segunda sprint review suele mostrar si los stakeholders seguirán en la sala en la sexta.

La solución es sobre todo estructural. Cambias para qué sirve la reunión y luego cambias la agenda para que la sala tenga que tomar decisiones. Esta guía cubre el propósito, una agenda cronometrada, quién habla y cuándo, cómo recoger feedback sin ahogarte en peticiones de funcionalidades y qué hace el Product Owner después.

Por qué los stakeholders dejan de asistir a las sprint reviews

Aquí los stakeholders se comportan de forma racional. Cuando una review es un recorrido guionizado por pantallas terminadas sin ninguna pregunta abierta sobre la mesa, concluyen, con razón, que su presencia no cambia nada. Primero envían a alguien en su lugar, luego declinan la invitación y, al final, la convocatoria desaparece de su calendario.

Este es un caso típico. Un equipo de producto hace una demo de un flujo de pago terminado durante 45 minutos y no hace a los stakeholders ni una sola pregunta. Para el tercer Sprint, solo sigue conectándose el responsable del PO, y se pasa todo el rato contestando mensajes de Slack. Es uno de los antipatrones más comunes de la sprint review: el equipo hace una demo, que muestra lo que se ha construido, y la llama review, que inspecciona lo que se ha construido y decide qué debería cambiar a continuación.

El entorno general de reuniones lo empeora. El Work Trend Index de Microsoft informó en 2022 de que las reuniones semanales del usuario medio de Teams habían aumentado considerablemente desde el inicio de la pandemia, sin señales de que la tendencia fuera a invertirse. Cuando los calendarios se llenan, la gente abandona primero las reuniones que parecen actualizaciones pasivas. Una demo es lo más pasivo que puede ser una actualización, y quien pueda leer las notas de la versión en su lugar acabará haciéndolo.

Para qué sirve una sprint review según la Scrum Guide

La Scrum Guide de 2020 es breve y clara al respecto. El propósito de la Sprint Review es inspeccionar el resultado del Sprint y determinar las adaptaciones futuras. El Scrum Team presenta los resultados a los stakeholders clave, se comenta el progreso hacia el Objetivo del Producto y los asistentes colaboran en qué hacer a continuación. El Product Backlog puede ajustarse para aprovechar nuevas oportunidades.

La frase más útil para los equipos es esta: la Sprint Review es una sesión de trabajo, y el Scrum Team debería evitar limitarla a una presentación. El incremento es la entrada de la conversación. La salida es una decisión sobre el backlog.

Lo mismo vale desde el lado de los stakeholders. La review existe porque las personas que van a usar, financiar o dar soporte al producto saben cosas que el equipo no sabe, y el backlog debería cambiar una vez que han visto software funcionando.

En cuanto a la duración, la Scrum Guide limita el evento a cuatro horas para un Sprint de un mes y espera que los Sprints más cortos usen proporcionalmente menos. Para un Sprint de dos semanas, eso significa dos horas como máximo. En la práctica, de 60 a 90 minutos suele bastar. Un límite fijo, por ejemplo 75 minutos, funciona mejor cuando el equipo lo trata como una restricción de diseño que le obliga a recortar la narración y proteger la conversación.

Sprint review frente a retrospectiva frente a sprint planning

Estos tres eventos se confunden a menudo, y eso hace perder mucho tiempo a los stakeholders.

Evento	Qué se inspecciona	Quién asiste	Qué cambia
Sprint Review	El incremento del producto y el contexto de mercado o de negocio	El Scrum Team más los stakeholders clave	El Product Backlog
Retrospectiva del Sprint	Cómo trabaja el equipo: proceso, herramientas, colaboración	Solo el Scrum Team	La forma de trabajar del equipo
Sprint Planning	El backlog adaptado y la capacidad del equipo	El Scrum Team, con otras personas invitadas según haga falta	El Sprint Backlog del siguiente Sprint

La Review mira el producto. La Retrospectiva mira al equipo. El Planning toma lo que decidió la Review y lo convierte en un compromiso para el siguiente Sprint, lo que cierra el ciclo.

Un desbordamiento habitual va de la Retrospectiva a la Review. Durante la demo, un developer comenta que el pipeline de despliegue es demasiado lento, otros dos se suman y, de repente, seis stakeholders están viendo un debate sobre herramientas internas sobre el que no pueden hacer nada. Esa conversación corresponde a la Retrospectiva. Si tus retros no tratan bien estos temas, nuestra guía completa para facilitar la Sprint Retrospective cubre el formato en detalle. El desbordamiento inverso también ocurre: un equipo dedica la mitad de su Retrospectiva a volver a discutir las prioridades del backlog, que es decisión del PO y debería haberse zanjado con los stakeholders en la sala.

Una agenda de sprint review de 60-90 minutos

Esta agenda es para un Sprint de dos semanas con entre cinco y doce stakeholders. Dura unos 85 minutos, lo que deja un pequeño margen.

• Minutos 0-5: Objetivo del Sprint y contexto. El PO enuncia el objetivo y dice claramente si se ha alcanzado, se ha alcanzado en parte o no se ha alcanzado. Una frase sobre cualquier cosa que haya cambiado en el negocio desde la última review.
• Minutos 5-35: Recorrido por el software funcionando. Solo elementos que cumplen la Definición de Terminado, mostrados en directo en un entorno real. Sin diapositivas, sin maquetas de trabajo sin terminar.
• Minutos 35-60: Feedback estructurado de los stakeholders, con preguntas concretas (que se explican más abajo). Cada aportación se registra de forma visible en cuanto se plantea.
• Minutos 60-80: Impacto en el backlog. Qué se añade, se reprioriza o se elimina como resultado de lo que acabamos de oír. El PO toma las decisiones o dice cuándo se tomarán.
• Minutos 80-85: Recapitulación de decisiones y responsables, leída en voz alta desde la pantalla compartida.

Para una versión de 60 minutos, reduce el recorrido a 20 minutos y el bloque de feedback a 15. No recortes nunca el segmento de impacto en el backlog, porque es lo que convierte esto en una review.

El Atlassian Agile Coach describe una review típica como algo que empieza con un resumen del Objetivo del Sprint, seguido de las demostraciones. Hay una razón práctica para ese orden: si el objetivo no se alcanzó, decirlo en el minuto dos cambia la forma en que la gente ve los 30 minutos siguientes. Buscan lo que se ha aprendido en lugar de puntuar el acabado. Mike Cohn, de Mountain Goat Software, defiende que las reviews sean informales y ligeras, sin diapositivas pulidas. Las diapositivas transmiten «presentación», y los stakeholders responden recostándose en la silla.

Un añadido útil para cualquier review es una sección visible de «Decisiones tomadas» en la pantalla compartida, que se rellena en directo. Sin ella, los equipos tienden a volver al enseñar y contar, porque nada en la estructura empuja a nadie a decidir. Puedes guardar esta agenda como plantilla reutilizable en Workshop Weaver para que el bloque de decisiones y sus tiempos vengan incorporados en cada Sprint en lugar de reconstruirse de memoria.

Quién habla y cuándo

Unos roles claros evitan que una reunión de 12 personas se convierta en un monólogo del PO o en un caos.

Los Developers presentan su propio trabajo

La Scrum Guide de 2020 no asigna a nadie para presentar, pero las ediciones anteriores hacían que el Development Team demostrara el trabajo que había completado, y esa sigue siendo la mejor opción por defecto. Cuando tres developers distintos muestran cada uno la pieza que han construido, los stakeholders obtienen respuestas directas a las preguntas técnicas y empiezan a confiar en el equipo en su conjunto. Cuando el PO lo presenta todo en nombre del equipo, cada pregunta difícil se convierte en «Lo consulto con los developers y te digo algo», y la reunión pierde gran parte de su valor.

El Product Owner abre, escucha y cierra

El PO enmarca el Objetivo del Sprint al principio y las implicaciones para el backlog al final. En medio, el trabajo del PO es escuchar e indagar. Un PO que habla más de aproximadamente un tercio de la reunión suele estar defendiendo el incremento en lugar de aprender de la reacción que provoca.

El Scrum Master protege el time-box y el equilibrio

El Scrum Master facilita. Eso significa respetar los tiempos, asegurarse de que el stakeholder que más alza la voz no fije el backlog a base de volumen y redirigir a la Retrospectiva los temas de proceso o interpersonales en cuanto salen a la luz. Basta una frase sencilla: «Eso es una cuestión de proceso del equipo, lo he anotado para la retro. Volvamos al flujo de pago».

Cómo obtener feedback de los stakeholders sin una avalancha de peticiones de funcionalidades

«¿Qué les parece?» es una mala pregunta para una sprint review. Invita a opiniones dispersas y listas de deseos, y acabas con 14 peticiones de funcionalidades y ninguna decisión.

Las preguntas más acotadas producen feedback sobre el que se puede actuar:

• ¿Qué te ha sorprendido de lo que acabas de ver?
• ¿Qué falta que te impediría usar esto hoy?
• ¿Qué cambiarías antes de ponerlo delante de clientes?
• ¿Ha cambiado algo por tu lado desde el último Sprint que debería cambiar nuestras prioridades?

Haz una pregunta cada vez y da a la gente 60 segundos de silencio para escribir antes de que nadie hable. En una sesión remota, eso significa un tablero compartido. En una sala, pósits. El paso de escritura en silencio evita que la primera voz sénior ancle a todas las demás.

Después, aplica una regla firme: registrar ahora, priorizar después. Cada aportación se convierte en una tarjeta en una columna de «Feedback de la review» en la herramienta del backlog. En la Review no se dimensiona, se estima ni se compromete nada. Ese trabajo ocurre en el refinamiento, y nuestra agenda de la reunión de refinamiento del backlog explica cómo convertir esas tarjetas en bruto en elementos dimensionados y listos. Sin esta regla, la Review se convierte en una sesión de planificación improvisada y se sale de su time-box en cada Sprint.

Cuando sí necesitas saber rápidamente qué feedback importa más, un tablero de ahora/después/más adelante o una ronda de votación por puntos permite que la sala exprese prioridades en dos minutos. El PO sigue siendo el responsable del orden del backlog; la votación es una aportación. Si usas votación, infórmate sobre cómo usar la votación por puntos sin caer en el pensamiento de grupo, porque una sala de stakeholders que ve a su VP colocar los puntos primero copiará al VP.

Qué hace el Product Owner con el resultado

Las ediciones anteriores de la Scrum Guide describían el resultado de la Sprint Review como un Product Backlog revisado que muestra los elementos probables para el siguiente Sprint. La redacción de 2020 es más suave, pero el trabajo no ha cambiado. El PO traduce la conversación en cambios concretos y ordenados del backlog en un día o dos. Las promesas verbales hechas en la sala no bastan. Si un stakeholder oye «sí, lo miraremos» y nunca vuelve a ver el elemento, aprende que la reunión es teatro.

La práctica que más contribuye a recuperar la implicación es cerrar el ciclo de forma visible. Abre cada review con un breve segmento de «La última vez nos dijeron»: tres aportaciones de reviews anteriores y qué pasó con cada una: entregada, programada o descartada con un motivo. Descartada cuenta, porque los stakeholders pueden vivir con un no. Lo que los aleja es no oír nada.

El backlog adaptado pasa después directamente al siguiente Sprint Planning. Si la planificación se hace esa misma tarde o a la mañana siguiente, el equipo selecciona el trabajo con lo que los stakeholders acaban de decir en mente, en lugar de planificar a partir de un backlog que ya lleva dos semanas desfasado.

Hábitos de facilitación que la mantienen como una reunión de decisión

Unos pocos hábitos separan las reviews que siguen siendo útiles de las que se deterioran.

Envía una lectura previa 24 horas antes. Media página: qué estaba planificado, qué está terminado, qué no está terminado y las dos o tres preguntas abiertas sobre las que quieres la aportación de los stakeholders. Esto saca la narración de la reunión y da a los stakeholders tiempo para formarse una opinión. Las preguntas abiertas también le dicen a cada persona por qué debería asistir precisamente ella.

Nombra a una persona responsable de decidir cada asunto abierto al cierre. «Pensaremos en la funcionalidad de exportación» es una conversación. «Priya decide antes del jueves si la exportación pasa por delante de la búsqueda» es una decisión. Lee la lista en voz alta antes de que la gente se vaya.

Mide lo correcto. La Sprint Review existe para inspeccionar el incremento y adaptar el backlog, así que mide la adaptación. Una cifra útil que seguir de un Sprint a otro: los elementos del backlog añadidos, repriorizados o eliminados como resultado directo de la Review. Si tiende a cero a lo largo de tres Sprints, trátalo como una prueba de que la reunión ha vuelto a caer en el modo demo y rediseña el bloque de feedback. La asistencia y el acabado de la demo te dicen muy poco.

Tres eventos, un ciclo de inspección y adaptación

La Sprint Review es la única reunión recurrente en la que el backlog puede cambiar legítimamente delante de las personas a las que más afecta. Diseña la agenda en torno a ese cambio: abre con el Objetivo del Sprint, muestra solo trabajo terminado, haz preguntas acotadas y reserva de 15 a 20 minutos para las decisiones sobre el backlog con responsables nombrados.

Después, conéctala con los otros dos eventos. Los problemas de proceso que surgen en la Review van a la Retrospectiva, y nuestra guía completa para facilitar la Sprint Retrospective explica cómo llevar esa conversación. Las tarjetas de feedback que registras van al refinamiento, donde la agenda de la reunión de refinamiento del backlog las convierte en trabajo dimensionado y listo para el siguiente Sprint Planning. Facilita los tres como un único sistema y los stakeholders seguirán viniendo, porque cada review les muestra qué cambió su última ronda de feedback.