Sprint Review

¿Qué es la Sprint Review?

Es uno de los eventos en 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, una sesión de trabajo, no una presentación unidireccional o un mero reporte del Equipo Scrum. No es una reunión de seguimiento o de “control” al Equipo, ni 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 Product 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. Es, por tanto, un evento que mira hacia delante.

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

  • El Product Owner arranca recordando la visión de producto, así como el Product Goal en el que el Equipo Scrum está trabajando.
  • El Product Owner explica cuál fue el objetivo del Sprint y cómo encaja dentro de la realización del Product Goal.
  • Los Desarrolladores hacen una demostración del Incremento y comentan el trabajo realizado durante el Sprint, incluyendo qué problemas acaecieron y cómo fueron resueltos; esta parte da a los stakeholders la oportunidad de que aporten sus opiniones y realicen preguntas.
  • Alguno de los miembros del Equipo Scrum indica impedimentos que afectan al Equipo y a cuya resolución puedan contribuir los stakeholders presentes.
  • Debate sobre cambios en el mercado o industria.
  • Revisión entre todos del Product Backlog en su estado actual y de qué es probable que entre en el siguiente Sprint.
  • Repaso del plan de lanzamiento y presupuesto por parte del Product Owner (por ejemplo, utilizando un Release Burn Down chart).

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

  • Ya no se indica que es el Product Owner quien ha de invitar a los stakeholders a la Sprint Review, luego esta invitación podría ser extendida por otros miembros del Equipo Scrum. Con todo, lo normal es que el Product Owner siga asumiendo esta tarea, pues es quien activamente gestiona la relación con los stakeholders.
  • Tampoco se señala que la presentación o demostración del resultado del Sprint deba ser efectuada por los Desarrolladores. En teoría, por tanto, la presentación podría correr a cargo del Product Owner o, incluso, del Scrum Master. No obstante, pensamos que lo conveniente para fomentar la autogestión del Equipo Scrum será que los Desarrolladores sean quienes continúen realizando la demo de la Sprint Review, pues son son quienes construyen el producto.

¿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. Como indican Barry Overeem y Christiann Verwijs, la pregunta clave a la que intentamos responder con la Sprint Review es la siguiente: teniendo en cuenta lo que hemos aprendido durante este Sprint, ¿Cuáles son los pasos siguientes? La respuesta determinará adaptaciones del Product Backlog e influirá en los elementos del Product Backlog que serán seleccionados durante Sprint Planning y en los Objetivos del Sprint venideros.

Es, como decíamos, una sesión para que el Equipo Scrum y los stakeholders colaboren. Es una reunión de trabajo. No es una demo unidireccional ni un «show and tell», es una sesión en la que recibir feedback por parte de los stakeholders. Debe ser algo así como una “fiesta del feedback«. 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 producto que estamos desarrollando y al plan (Product Backlog) que estamos siguiendo. Compartir el Incremento puede ser parte de ello, pero hay muchas otras cosas que traen contexto acerca del producto y que hacemos transparentes e inspeccionamos durante la Sprint Review.


El papel del Product Owner en la Sprint Review

El Product Owner es el anfitrión de la Sprint Review. Ahondando en la agenda propuesta anteriormente, el Product Owner hará cosas como:

▶ Decide a qué stakeholders hay que invitar (y la convocatoria debe salir de su calendario).

▶ Aporta contexto al Incremento de Producto, compartiendo con el grupo el Product Goal y el Sprint Goal.

▶ Es el principal interesado en obtener feedback de los stakeholders. En sentido amplio: sobre el producto en sí y sobre el mercado o cualquier aspecto que pueda afectar a su desarrollo.

▶ Es el principal interesado en alinearse con los stakeholders sobre qué hacer en el siguiente Sprint.

▶ Actualiza al resto en cuanto a presupuesto y fechas de entrega posibles.


¿Siempre hay que hacer una “demo” del Incremento de Producto durante la Sprint Review?

En muchos casos, ni si quiera hace falta hacer una demo.

Si hemos desplegado en producción antes de la Sprint Review, como suele pasar con Equipos que hacen continuous deployment:

a) Los stakeholders pueden verlo/usarlo en producción, antes, durante o después.

b) Podemos ir a la Review con datos de uso contantes y sonantes, que informan la conversación y la toma de decisiones. 


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 Sprint 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 un 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 siempre que sea necesario.


2/ Los stakeholders no asisten a la Sprint Review. En este caso, los stakeholders han sido invitados por el Equipo Scrum, pero no se presentan a la sesión, ya sea por falta de tiempo o de interés o de ambos. De nuevo, esto puede privar al Equipo de feedback clave sobre cómo seguir iterando.

El primer paso es hacer ver a estos stakeholders lo importante que son sus aportaciones para guiar los pasos del Equipo Scrum. Sé de equipos que, cuando los esfuerzos diplomáticos por hacer que estos stakeholders asistan a la Sprint Review no llegan a buen puerto, han dado prioridad a Incrementos que añaden valor a otros stakeholders.


3/ Hay demasiados stakeholders. No todos los posibles interesados tienen que estar en la Sprint 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 Sprint Review u otros motivos. Stakeholders que de verdad no son tales tan solo añadirán “ruido” a la sesión.  


4/ El Product Owner utiliza la Sprint 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 Sprint Review, mal síntoma. Si el propio Product Owner se encuentra con “sorpresas” durante la sesión, ni imaginemos cómo de confundidos pueden quedar los stakeholders.

La Sprint 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” tras el 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.


5/ 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 Sprint 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 Sprint Review y el espíritu de Scrum como framework. Puede que sea necesario trabajar con los stakeholders de manera separada en este sentido.


6/ Presentamos funcionalidades no terminadas. Si en la demo se incluyen funcionalidades que no han sido lo suficientemente testeadas o que no han sido integradas, que no cumplen con la Definición de Hecho, esteremos creando falsas expectativas en los stakeholders. Habrá falta de transparencia. 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, dando 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 Sprint 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.  


7/ 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. Si eres Scrum Master, 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.


8/ 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 o hacer pair programming o, incluso, 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.


9/ 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.


10/ 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:

  • Variar la estructura de la reunión, para que no resulte monótona.
  • Implicar más a los stakeholders; por ejemplo, no haciendo una demostración como tal, sino dejando que uno o varios o todos prueben el Incremento “sobre la marcha”.
  • Hacer uso de liberating structures como 1-2-4-All, para, por ejemplo, propiciar que todos los asistentes participen a la hora de indicar sus prioridades para el próximo Sprint, información que el Product Owner podrá utilizar. Puedes leer más sobre las estructuras liberadoras en este enlace.

11/ Nos saltamos la Sprint 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.


¿Hay que esperar a la Sprint Review para poner el Incremento en producción?

No. La Sprint Review no es un evento para la aprobación del Incremento, ni por parte de los stakeholders ni del Product Owner. No hay que esperar. Tal y como un elemento del Product Backlog cumpla con la Definición de hecho, es potencialmente desplegable. Por ejemplo, si un Equipo utiliza continuous deployment, lo normal será que lance múltiples Incrementos a producción durante el Sprint (incluso, múltiples veces al día). Como señalábamos antes, esto puede permitirnos acudir a la Sprint Review con métricas de uso que enriquezcan la colaboración.


< Volver a Scrum

Cuando estés listo, podemos ayudarte de 3 formas

  1. 1. Únete a nuestra Newsletter, Líderes de Producto: recibe contenidos exclusivos sobre Agile y Product Management.
  2. 2. Apúntate a una de nuestras formaciones: cursos intensivos para Product Owners/Managers y Scrum Master/Agile Coaches, en directo e impartidos por nuestros especialistas.
  3. 3. ¿Quieres formar a tu equipo? Hacemos formaciones “privadas” para empresas, con las que transformar vuestra forma de trabajar. Somos especialistas en Scrum y Product Management.