Sprint Review

¿Qué es la Sprint Review?

Es uno de los eventos o ceremonias de Scrum, que tiene lugar al final del Sprint, antes de la Sprint Retrospective. En esta reunión el Equipo Scrum al completo (Product Owner, Scrum Master y Desarrolladores) colabora con los interesados clave o stakeholders (representantes de otros departamentos de la organización, clientes, usuarios, etc.) para inspeccionar el Incremento de Producto y, en su caso, adaptar el Product Backlog. Su duración máxima o timebox para Sprints de un mes es de cuatro horas (proporcionalmente menos para Sprints de menor duración).

Hay que hacer énfasis en que debe ser una sesión colaborativa e informal, no una presentación unidireccional o un mero reporte del Equipo Scrum. No es una reunión de seguimiento o de “control” al Equipo. Tampoco debe ser una demo sin más del Incremento de producto. El resultado de la Sprint Review debiera ser un Product Backlog revisado y que nos dé una idea clara acerca de los elementos que probablemente serán seleccionados en el siguiente Sprint. Esta revisión del Backlog es consecuencia de la inspección del Incremento, del feedback aportado por los stakeholders y posibles cambios en el mercado o en la tecnología.

Por ejemplo, una posible agenda o estructura para la Sprint Review podría ser la siguiente.

Tras la última actualización de la Guía Scrum en 2020, por cierto, se eliminan un par de prescripciones de cierta relevancia:


¿Para qué sirve la Sprint Review?

Su propósito es comentar abiertamente cómo fue el Sprint, qué resultado hemos obtenido y hacia dónde vamos. Es, como decíamos, una reunión para que el Equipo Scrum y los stakeholders colaboren. Es una reunión de trabajo. Por tanto, todo el Equipo Scrum debe estar presente y preparado para participar y resolver las preguntas e inquietudes que los interesados clave planteen.

La celebración de la Sprint Review y asistencia de todos los miembros del Equipo Scrum y de los stakeholders relevantes nos permitirá crear transparencia en torno al software que estamos desarrollando y al plan (Product Backlog) que estamos siguiendo. 


Problemas comunes que afectan a la Sprint Review y estrategias de mejora

La Sprint Review puede adolecer de problemas varios que entorpezcan la realización de su propósito. El Scrum Master, que en general no debe asumir un papel protagonista, menos aún lo hará en la Review. No obstante, sí que ha de observar su devenir activamente, a fin de identificar estos vicios y promover estrategias con las que mitigarlos.


1/ Los stakeholders relevantes no han sido invitados por el Product Owner. Esto acarreará falta de transparencia a la hora de inspeccionar el Incremento y adaptar el Product Backlog. El Equipo Scrum podría estar omitiendo feedback crítico para la viabilidad del producto y perder la confianza del resto de la organización. Podríamos estar navegando a la deriva.

Recuerdo un caso en el que el Project Manager -no procede su consideración como Scrum Master, su desconocimiento de Agile era profundo, por desgracia- intentaba evitar al CEO a toda costa, procurando que no viera ningún Incremento, a pesar de tratarse de un nuevo producto con carácter estratégico para la organización. Supuestamente, de esta forma, el Project Manager buscaba proteger al Equipo y poder avanzar más rápido. Craso error: hubo retrasos en la resolución de impedimentos y en los plazos de entrega, desconfianza y otros problemas. El Project Manager terminó fuera de la empresa.

Como Scrum Masters, debemos asegurarnos de que los stakeholders han sido identificados por el Product Owner e invitados a la Sprint Review. Si quiénes son estos interesados clave no está del todo claro, nos tocará ahondar en la búsqueda: ¿Quiénes tienen poder de decisión respecto al producto? ¿Quiénes pueden ver alterado su trabajo como consecuencia? ¿Quiénes interactuarán de forma diferente con los clientes cuando el producto sea desplegado en producción? Ayudemos al Product Owner a realizar este ejercicio cuando sea necesario.


2/ Hay demasiados stakeholders. No todos los posibles interesados tienen que estar en la Review. Habrá algunos a los que simplemente podemos tener informados por otras vías, bien porque no tengan un interés tan intenso en el producto, bien por falta de disponibilidad para estar presentes en cada Review u otros motivos. Stakeholders que de verdad no son tales tan solo añadirán “ruido” a la sesión.  


3/ El Product Owner utiliza la Review para aceptar o rechazar los elementos del Product Backlog supuestamente completados en el Sprint. Está disfunción denota falta de colaboración entre el Product Owner y los Desarrolladores. Durante el Sprint, estos han debido comunicarse frecuentemente, ya sea para ofrecer feedback por parte del Product Owner, ya sea para resolver las dudas que le surjan a los Desarrolladores a medida que trabajan en la funcionalidad del Sprint. Si el Product Owner ve el Incremento por primera vez en la Review, mal síntoma. Si el propio Product Owner se encuentra con “sorpresas” en la Review, ni imaginemos cómo de confundidos pueden quedar los stakeholders.

La Retrospective puede servirnos para analizar la comunicación entre Product Owner y Desarrolladores. Por ejemplo, si nuestro Product Owner está tan atareado que prácticamente “desaparece” una vez hecha la Sprint Planning, podría ser conveniente que acordemos bloquear ciertas horas a la semana en su agenda, a modo de “horas de tutoría”, para que durante ese tiempo los Desarrolladores sepan que está disponible para hablar sobre el producto.

En este artículo comentamos las interacciones principales entre Product Owner y Desarrolladores durante el Sprint.


4/ Los stakeholders son los que utilizan la Review para aceptar o rechazar el Incremento. En estos casos, la colaboración entre Equipo Scrum y stakeholders brilla por su ausencia. El Equipo presenta lo que ha hecho, a modo de reporte, y todo depende de si es del agrado o no de los stakeholders, en especial de aquellos con más peso. El devenir de la Review depende del humor de “los jefazos” o del cliente. La crítica no suele ser constructiva, sino destructiva. Se buscan culpables. La autoridad del Product Owner es así menoscabada, y los stakeholders pueden terminar rechazando el Incremento o, en los casos más severos, cancelando el proyecto en su totalidad.

Aquí el buen Scrum Master tendrá que tomar cartas en el asunto e intentar aclarar cuál es el propósito de la Review y el espíritu de Scrum como framework. Puede que sea necesario trabajar con los stakeholders de manera separada en este sentido.


5/ Presentamos funcionalidades no terminadas. Si en la demo se incluyen funcionalidades que no han sido lo suficientemente testeadas o que no han sido integradas, esteremos creando falsas expectativas en los stakeholders. Si recurrimos a la típica presentación de “cartón piedra”, ya sea con pantallas sin back-end, mock-ups o power point puro y duro, dondo la falsa impresión de que todo está ya funcionando, pues casi pero aún.

Cuando no hemos podido entregar tanto como los stakeholders y nosotros mismos hubiéramos querido, en vez de “falsear” los resultados del Sprint, seamos honestos durante la Review y hablemos de las complejidades a las que tuvimos que hacer frente y de los impedimentos existentes. Recordemos aquí la importancia de dos de los valores Scrumopenness y courage.  


6/ La Sprint Review se ha convertido en una demo (y ya está). Este es uno de los vicios más extendidos. La Review no debe consistir en una mera presentación del Incremento de producto. Su propósito, como hemos señalado, es bastante más amplio. Considera hablar con el Product Owner y los Desarrolladores para establecer una agenda más completa que fomente la colaboración entre el Equipo Scrum y los stakeholders, como la que vimos más arriba.


7/ Cada desarrollador presenta “su parte” y “se lava las manos”. En Scrum, la responsabilidad respecto a la consecución del Objetivo del Sprint y sobre el Incremento como tal recae sobre el Equipo Scrum en su conjunto. Los elementos del Product Backlog no “pertenecen” a unos miembros y no a otros. El Incremento lo creamos entre TODOS. Cuando durante la demo cada Desarrollador se limita a presentar aquella funcionalidad en la que ha trabajado individualmente, en algunos casos “vendiendo” al resto del grupo su buen hacer, lo único que demostramos es falta de auto-gestión como Equipo.

En estas situaciones, en las que difícilmente estaremos entregando Incrementos terminados, podemos invitar a que el Equipo experimente con diversas prácticas que favorezcan el trabajar como una unidad, como limitar el número de elementos en curso durante el Sprint, hacer pair programming o mob programming. Otro ejercicio interesante puede ser probar a “prohibir” el uso de la primera persona del singular (“yo”), durante la Review o, más allá, durante todo el Sprint.


8/ Algunos Desarrolladores se niegan a hablar. Sí, todos lo hemos visto. Hay Desarrolladores tan introvertidos que eluden hablar en público a toda costa. Para eso nos metimos en informática, ¿no? ¡Pues no! En Scrum en particular y Agile en general, la comunicación es esencial.

Ojo, no se trata de obligar ni forzar a nadie. Hablar en público, siquiera ante un grupo reducido, causa auténtico pavor a muchas personas. Si alguno de los Desarrolladores tiene dificultades para exponer o presentar, aprovechemos la oportunidad para entrenar esta faceta.


9/ La reunión es soporífera. Los stakeholders y el propio Equipo Scrum están mirando los portátiles, el móvil, hay gente que entra y sale de la reunión, etc., deseosos de que la tortura termine y puedan, por fin, escapar.

El Scrum Master debe ayudar a que el Product Owner, en su papel de anfitrión de la Sprint Review, obtenga el máximo provecho de la misma y se lleve todo el feedback necesario. Algunas prácticas para mantener al grupo involucrado pueden ser:


10/ Nos saltamos la Review. Como este Sprint no hemos conseguido entregar un Incremento de producto terminado, hemos pensado que mejor no hacer la Review. Total, para qué. Ya en la siguiente Review haremos una demo en condiciones y nos pondremos las “medallas”. O alguno de los jefazos no puede asistir y la aplazamos. O cualquier otra excusa barata. Recuerdo un proyecto en el que, como la Review era más bien una suerte de reporte a los stakeholders o steering commitee en el que “recibir palos”, rezábamos porque la Review no se produjera…

La Review hay que hacerla al final de cada Sprint, sí o sí. No perdamos la ocasión de inspeccionar el Incremento. Y, si no hay Incremento, pues seamos valientes y hablemos de qué ha pasado durante el Sprint y de sus posibles efectos sobre el Product Backlog.


< Volver a Scrum