Go to Scrumio.com

Sprint Review: problemas comunes y cómo atajarlos

En este post revisamos el concepto y propósito de la Sprint Review y, sobre todo, abordamos los vicios de los que frecuentemente adolece, junto con posibles sugerencias de mejora.


¿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 miembros del Equipo de Desarrollo) colabora con los interesados clave o stakeholders invitados por el Product Owner (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).

Hago énfasis en que debe ser una sesión colaborativa e informal, no una presentación unidireccional o un mero reporte del Equipo Scrum, ni tampoco una demo sin más del Incremento de producto. El resultado de la Sprint Review debiera ser un Product Backlog revisado y que nos de 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.

– El Product Owner arranca recordando la visión de producto.

– El Product Owner explica cuál fue el objetivo del Sprint y cómo encaja dentro de la visión de producto.

– Varios de los miembros del Equipo de Desarrollo hacen una demostración del Incremento y comentan el trabajo realizado durante el Sprint, incluyendo qué problemas acaecieron y cómo fueron resueltos; oportunidad para que los stakeholders aporten sus opiniones y realicen preguntas.

– Alguno de los miembros del Equipo de Desarrollo 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).


¿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 el Equipo de Desarrollo. Durante el Sprint, estos han debido comunicarse frecuentemente, ya sea para ofrecer feedback por parte del Product Onwer, 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 Equipo de Desarrollo. 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 el Equipo de Desarrollo sepa que está disponible para hablar sobre el producto.


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, y 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. 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, que da 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 Scrum: openness y courage.  


6/ La Sprint Review se ha convertido en una demo (y ya está). 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 el Equipo de Desarrollo 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 de Desarrollo 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-organizació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, incluso mejor, 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, si quiera 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:

– 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.


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.


¿Cómo hacéis la Sprint Review? ¿Qué aspectos a mejorar habéis identificado?


Imagen: Vector de Carácter creado por macrovector – www.freepik.es

Comparte este post

Publicado por Sergio Rodríguez

Chief Product Officer and Product Consultant for several international startups throughout his career, such as Liftshare.com, Hiyacar and Cardmarket. Agile practitioner for over 10 years and PSPO III certified. Obsessed with creating products that people love.

Posts relacionados

Comentarios

Deja tu comentario

Tu dirección de correo no será publicada. Lo campos requeridos están marcados con *

Recibe artículos sobre ágil y promociones en tu email.