Publicaciones

Cómo realizar sprint reviews a las que los stakeholders realmente quieran asistir

La mayoría de los sprint reviews siguen el mismo guion: el equipo revisa una lista de tickets completados, los stakeholders asienten educadamente, alguien dice "se ve bien" y todos se van. Sin retroalimentación real. Sin correcciones de rumbo. Solo una ceremonia que llena un espacio en el calendario. Se supone que el sprint review es donde los stakeholders dan forma a la dirección del producto. Cuando funciona, los equipos construyen lo correcto. Cuando no funciona, se enteran meses después de que nadie quería lo que entregaron. Así es como arreglarlo.

Deja de llamarlo demo

El mayor error conceptual sobre los sprint reviews es que son demos de producto. Una demo es unidireccional: el equipo muestra, la audiencia observa. Un sprint review es una conversación bidireccional sobre hacia dónde se dirige el producto. La demo es parte del review, pero no es todo. Un sprint review sólido también cubre:

• Qué cambió en el mercado, con los clientes o en el roadmap desde el último sprint
• Si el equipo está en camino hacia el objetivo del producto y qué dicen los datos
• Qué construir a continuación basándose en lo que los stakeholders acaban de ver

Cuando los equipos omiten estas conversaciones y solo muestran trabajo completado, los stakeholders no tienen razón para involucrarse. Están viendo una presentación que podrían haber recibido en un email.

Por qué los stakeholders dejan de aparecer

Antes de arreglar el formato, ayuda entender qué aleja a las personas:

Problema	Qué sucede
Sin impacto visible	Los stakeholders dieron retroalimentación la última vez y nada cambió
Demasiado granular	45 minutos de pequeños ajustes de UI y correcciones de bugs que nadie pidió
Horario de viernes por la tarde	Compitiendo con el cansancio de fin de semana y salidas tempranas
Formato pasivo	Sin oportunidad de hacer preguntas o probar cosas
Sin contexto	Funcionalidades mostradas sin explicar por qué importan o para quién son

El mayor asesino de asistencia es el primero. Si los stakeholders ven que se actúa sobre su retroalimentación, vuelven. Si no lo hacen, no volverán.

Una agenda de sprint review que funciona

Para un sprint de dos semanas, planifica alrededor de 90 minutos. Aquí hay un formato que mantiene a los stakeholders comprometidos.

1. Establece el escenario (5 min)

   Bienvenida rápida, recuerda a todos el objetivo del producto y el objetivo de este sprint. Si hay caras nuevas, breves presentaciones. Sin diapositivas.

2. Comparte el contexto de negocio (10 min)

   El Product Owner cubre qué cambió desde el último review: retroalimentación de clientes, cambios en el mercado, métricas que se movieron. Este es el contexto que los stakeholders necesitan antes de poder dar retroalimentación útil sobre lo que están por ver.

3. Muestra software funcional (40-50 min)

   Demuestra el incremento. Solo muestra trabajo terminado que cumpla con tu Definición de Terminado. Después de cada funcionalidad, haz una pausa y pregunta a los stakeholders cuestiones específicas. No te apresures de un elemento al siguiente.

4. Recopila retroalimentación y discute próximos pasos (20-25 min)

   Discusión abierta sobre lo que se mostró. ¿Qué debería cambiar? ¿Qué falta? ¿En qué debería enfocarse el equipo a continuación? Captura todo de manera visible para que los stakeholders sepan que su aporte fue registrado.

5. Mira hacia adelante (5 min)

   Breve vista previa de lo que está planeado para el próximo sprint. Pregunta si las prioridades aún se sienten correctas dada la conversación de hoy. Anuncia la fecha del próximo review.

Nota que no hay un bloque de "presentar cada historia completada". No necesitas dar cuenta de cada ticket. Elige los elementos que necesitan aporte de stakeholders y omite el resto.

Hacer que la porción de demo sea realmente útil

La demo es donde la mayoría de los reviews salen mal, así que vale la pena ser específico sobre qué funciona. Deja que los stakeholders conduzcan. En lugar de compartir pantalla con un recorrido con guion, entrégales los controles. Pon el producto en sus manos, ya sea una URL de staging, un prototipo o una app en vivo en su dispositivo. Las personas dan mejor retroalimentación cuando experimentan algo de primera mano que cuando ven a alguien más hacer clic a través de ello. Haz preguntas específicas, no "¿alguna retroalimentación?" Las preguntas genéricas obtienen respuestas genéricas. En su lugar intenta:

• "¿Tu equipo usaría esto diariamente o solo durante la planificación?"
• "¿Falta algo antes de que esto sea útil para tu flujo de trabajo?"
• "Si pudieras cambiar una cosa sobre esto, ¿qué sería?"

Comienza con stakeholders senior. Si un VP habla primero, otros siguen. Si permanecen en silencio, todos los demás tienden a contenerse también. Dirige las primeras preguntas a las personas cuya retroalimentación tiene más peso. Omite las cosas triviales. No hagas demos de correcciones de bugs, cambios menores de estilo o refactorizaciones de backend a menos que un stakeholder específicamente las haya pedido. Mostrar cuarenta minutos de pulido incremental señala que nada significativo sucedió este sprint.

El ciclo de retroalimentación que hace que los stakeholders sigan volviendo

Obtener retroalimentación durante el review es solo la mitad del trabajo. Lo que haces con ella determina si los stakeholders aparecen la próxima vez. Actúa sobre la retroalimentación dentro de un sprint. Esto es lo más efectivo que puedes hacer. Los stakeholders necesitan ver que su aporte cambia lo que se construye. No tiene que ser todo. Incluso un cambio visible basado en la retroalimentación del último review construye confianza. Abre el próximo review con lo que cambió. Comienza mostrando cómo el equipo respondió a la retroalimentación del review anterior. "La última vez, mencionaron X. Esto es lo que hicimos al respecto." Esto cierra el ciclo y prueba que vale la pena aparecer en los reviews. No te comprometas con prioridades en el momento. Captura la retroalimentación, luego refinala y priorízala en refinamiento de backlog después. Los stakeholders quieren sentirse escuchados, no tomar decisiones de programación en tiempo real.

Sprint reviews remotos

Los equipos distribuidos enfrentan desafíos adicionales para mantener los reviews interactivos. Algunos ajustes ayudan. Comparte la agenda y el contexto con anticipación. Los asistentes remotos que llegan sin contexto tienen más probabilidades de permanecer en silencio todo el tiempo. Envía el objetivo del sprint, elementos clave a discutir y cualquier decisión sobre la que necesites aporte al menos un día antes. Usa salas de trabajo para retroalimentación. Después de la demo, divide en grupos pequeños de 3-4 personas para discutir funcionalidades específicas. Las llamadas de video grandes suprimen la participación. Los grupos más pequeños facilitan que las personas hablen. Pon el producto en sus manos antes de la reunión. Comparte un enlace de staging o una build de prueba con anticipación para que los stakeholders puedan explorar por su cuenta. El review se convierte en una conversación sobre lo que encontraron en lugar de un recorrido de primera vista. Usa formatos estructurados para la entrada. Encuestas en el chat, encuestas de Menti o un simple "califica esta funcionalidad del 1 al 10" en el chat dan a los introvertidos y a quienes llegan tarde una forma de contribuir sin activar el micrófono.

El formato de feria de ciencias para productos de múltiples equipos

Cuando múltiples equipos contribuyen a un producto, las demos secuenciales se vuelven insoportables. Nadie quiere sentarse durante dos horas de presentaciones de equipos con los que no interactúa. El formato de feria de ciencias arregla esto. Después de una breve reunión general del Product Owner (10 minutos sobre visión y roadmap), cada equipo establece un "stand", ya sea una sala de trabajo o una estación física. Los stakeholders rotan a través de los stands que son relevantes para ellos. Esto da a los stakeholders control sobre su tiempo. Pasan 15 minutos con el equipo construyendo sus funcionalidades, omiten las que no les importan y se van sintiendo que su tiempo fue respetado. Los equipos obtienen retroalimentación más profunda y enfocada en lugar de preguntas apresuradas al final de una reunión larga.

Qué debería (y no debería) hacer el Product Owner

El Product Owner dirige el sprint review, pero cómo lo dirige hace o rompe la reunión. Hacer:

• Preparar una agenda y compartirla con anticipación
• Proporcionar contexto de negocio que enmarca lo que el equipo construyó
• Facilitar la discusión en lugar de presentar todo tú mismo
• Dejar que los desarrolladores demuestren su propio trabajo
• Capturar retroalimentación y hacer seguimiento

No hacer:

• Presentar la demo como tu logro en lugar del equipo
• Aceptar o rechazar retroalimentación en el momento. Recopílala y evalúala después
• Usar el review como una aprobación formal o puerta de aceptación
• Saltarse el review cuando el objetivo del sprint no se cumplió completamente. Es cuando más necesitas el aporte de stakeholders

El último punto importa. Los equipos que cancelan reviews después de un sprint difícil pierden la transparencia que hace que scrum funcione. Un sprint que se quedó corto aún vale la pena revisarlo, y los stakeholders respetan la honestidad sobre lo que sucedió.

Medir si tus reviews están funcionando

No necesitas un tablero de métricas, pero presta atención a algunas señales:

• Tendencia de asistencia. ¿Los mismos stakeholders están apareciendo o estás perdiendo personas?
• Calidad de retroalimentación. ¿Estás obteniendo aporte específico o solo "se ve bien"?
• Cambios en el backlog después de reviews. ¿El review cambió lo que el equipo construye a continuación?
• Seguimiento de retroalimentación. ¿Cuánta de la retroalimentación del último review llegó a sprints subsecuentes?

Si la asistencia es constante, la retroalimentación es específica y el backlog se adapta basándose en lo que escuchas, tus reviews están funcionando. Si alguno de esos está plano, revisa el formato.

Sprint review vs. retrospectiva

Estas dos ceremonias de scrum suceden consecutivamente y los equipos a veces difuminan la línea entre ellas.

	Sprint review	Retrospectiva
Propósito	Inspeccionar el producto y adaptar el plan	Inspeccionar el proceso y adaptar cómo trabaja el equipo
Quién asiste	Equipo Scrum + stakeholders	Solo equipo Scrum
Enfoque	Qué se construyó y qué construir a continuación	Cómo trabajar mejor juntos
Resultado	Backlog de producto actualizado	Elementos de acción para mejora del proceso

El review mira hacia afuera (producto y stakeholders). La retrospectiva mira hacia adentro (equipo y proceso). Ambos importan, y uno no reemplaza al otro.