La sprint review es uno de los eventos más importantes en Scrum y, sin embargo, uno de los peor ejecutados. Lograr que el cliente interactúe directamente con el incremento de producto, en lugar de ver un video o una presentación, marca la diferencia entre obtener feedback real y construir sobre una falsa sensación de progreso.
¿Cómo preparar el terreno antes de inspeccionar el incremento?
Todo comienza con una actividad de check-in o rompehielo [0:18] que atraiga la atención de los asistentes. Aquí hay un matiz fundamental: en la sprint review deben participar los stakeholders, pero sobre todo los usuarios y el cliente final del producto. Uno de los valores del manifiesto ágil es la colaboración con el cliente, y aunque el product owner representa su voz, la presencia directa del usuario enriquece enormemente la conversación.
Una vez roto el hielo, el siguiente paso es presentar el objetivo del sprint [1:20]. Esto cumple dos funciones:
- Compartir una agenda clara para que los asistentes sepan qué esperar.
- Dar contexto sobre los compromisos que asumieron los developers en la sprint planning anterior.
No es necesario extenderse demasiado en esta etapa. Se trata de nivelar expectativas sin abrumar con detalles innecesarios.
¿Por qué la inspección directa del producto es insustituible?
El corazón de la sprint review es la inspección del incremento [2:12]. El cliente debe poder interactuar con el producto que ya contiene ese incremento. No basta con mostrar una presentación de diapositivas ni un análisis de datos.
Un principio del manifiesto ágil establece que el progreso se mide en función del valor entregado, no en cantidad de PBIs completados, historias de usuario cerradas o avance en un OKR [2:55]. Esas métricas pueden ser valiosas para una retrospectiva, pero en la sprint review desvían la conversación y confunden al cliente, que no puede dar feedback sobre estadísticas.
¿Por qué los demos y videos generan una falsa sensación de progreso?
Los demos en video suelen mostrar únicamente los escenarios felices [3:32]. El cliente no puede percibirse interactuando con el producto real, y esto provoca un problema serio: equipos que reciben aprobación en la sprint review pero, al lanzar la versión, descubren clientes insatisfechos.
Las quejas típicas son:
- «En el video no se demoraba tanto».
- «No me había fijado que tenía que hacer clic ahí».
- «El video pasó muy rápido».
Por eso, la demostración real del incremento debe ser el núcleo del evento [4:08].
¿Cómo recoger feedback valioso del cliente?
Una vez el cliente interactúa con el incremento, comienza la fase de recepción de feedback [4:18]. Pero no se trata solo de escuchar palabras:
- Observar el lenguaje no verbal del usuario.
- Preguntar si el incremento está resolviendo las necesidades que se plantearon al inicio.
- Abrir un espacio de discusión de iniciativas futuras, no como promesa, sino para entender la visión y las necesidades cambiantes del cliente.
Estos insights pueden incorporarse al product backlog para futuros sprints.
¿Cuál es el antipatrón más peligroso en la sprint review?
Uno de los errores más comunes es que el product owner se ausente durante todo el sprint y llegue a la sprint review como si fuera un cliente al que se le presentan resultados [4:55]. Esto contradice directamente el valor de colaboración con el cliente sobre negociación contractual.
Los proyectos tradicionales de software fracasaban precisamente porque el cliente o su representante estaban aislados del equipo que construía. Scrum resuelve esto integrando al product owner dentro del equipo. Él debe tener conocimiento total y diario de cómo evoluciona el incremento [5:28] y no debería sorprenderse con lo que se entrega al final del sprint.
El product owner no es alguien que recibe resultados: es corresponsable de lo que se entrega y debe estar del lado del equipo mostrando el incremento al cliente.
¿Cómo empoderar a los developers durante la revisión?
Una técnica de facilitación poderosa es que sean los developers quienes presenten el incremento al cliente [6:14]. Esto tiene beneficios concretos:
- Los developers conocen a los usuarios finales.
- Los stakeholders conocen a todo el equipo.
- Se evita que solo el product owner reciba el reconocimiento del trabajo colectivo.
- El equipo se siente más conectado y motivado con lo que construye.
Para cerrar el evento, es útil preguntar a los propios stakeholders y al cliente qué podemos hacer para que la próxima sprint review sea más eficiente [6:03]. Esta pregunta sencilla abre la puerta a la mejora continua del evento mismo.
¿Has identificado antipatrones similares en tus sprint reviews? Comparte tu experiencia y las acciones que incorporarías para transformar este evento.
