spinner

9 pasos para realizar con éxito un Sprint Review

Entre los eventos que se realizan en el framework de Scrum, se encuentra el Sprint Review. Se trata del momento en el que los stakeholders (grupos de interés de un producto) y el Scrum Team inspeccionan el incremento de producto terminado.

El Sprint Review es un evento que, como indica la Guía de Scrum, tiene como finalidad dar transparencia al incremento (la suma de todos los elementos del product backlog completados durante un Sprint y el valor de los incrementos de todos los Sprints anteriores) frente a los stakeholders y poder inspeccionar el product backlog para adaptarlo en función de las necesidades de mercado.

Dado que el evento tiene como objetivo revisar el incremento de producto, es fundamental que los stakeholders estén presentes. Si no, será difícil recoger feedback del producto y perdemos la ocasión de inspeccionar y adaptar si fuera necesario, corriendo el riesgo de desarrollar un producto no deseado.

1. Que se espera del evento

Para llevar a cabo el Sprint Review, el equipo Scrum recibe feedback acerca del progreso del desarrollo de producto. Este feedback puede ser proporcionado por los stakeholders, es decir, aquellos grupos de interés del producto: marketing, negocio, CIO, o el propio equipo de desarrollo. El devteam puede proponer tareas, que van a proporcionar mejoras de seguridad, rendimiento o cualquier otra cuestión de interés, normalmente de tipo técnico o tareas funcionales que puedan otorgar valor al producto.

El evento es una reunión informal (no se trata de un punto de control o seguimiento del equipo) en la que se recomienda llevar a cabo los siguientes puntos:

  • Recordar la visión del producto.
  • Exponer el Sprint Goal.
  • Mostrar el incremento del producto.
  • Recoger feedback de todos los invitados a la review (stakeholders y Scrum Team).
  • Revisión del product backlog entre todos y colaborar para determinar qué podría ser lo siguiente a desarrollar.
  • Revisión de cuál podría ser el valor en el siguiente incremento, según los cambios del mercado.
  • Revisión de los próximos pasos para la consecución de la release en curso.

2. Se muestra la agenda del evento

Para poner en contexto de forma rápida, es importante que, al principio del evento, se muestre la agenda que se va a llevar a cabo. De esta forma, todos los asistentes conocerán qué se va a revisar.

Ejemplo de Agenda de Sprint Review

Ejemplo de Índice para Sprint Review

En alguna ocasión, he asistido a Sprint Reviews de productos, para implementar un product backlog item (PBI). En el evento, han abierto Jira y únicamente nos han mostrado las tareas del Sprint Backlog. A partir de aquí, han comunicado los avances que ha realizado en los PBI. Sin embargo, en muchas ocasiones, no se han finalizado, y se explica lo “poco” que ha faltado para terminarlos.

Esto pone en evidencia un evento escaso en contenido y con falta de información que pueda indicarnos hacia dónde va su desarrollo y las mejoras competitivas que puedan posicionarlo por encima de la competencia o el valor que va a proporcionar a la empresa.

3. Revisamos la visión del producto

Tras hacer pública la agenda del evento damos un repaso de la “visión” del producto. Esto nos va a permitir conocer el objetivo principal, las soluciones que va a aportar a los clientes y el valor que les va a proporcionar.

Los stakeholders pueden intervenir en este momento para puntualizar algún aspecto de la visión. En este punto, tanto el Scrum Team como los stakeholders, iniciarían un debate para consensuar su actualización.

Actualización de la visión. Se aprecia al final del párrafo.

4. Sprint Goal y resumen de la evolución del sprint

Para que los asistentes del Sprint Review conozcan cuál es el incremento de producto que se ha trabajado, se indica cuál es el Sprint Goal para dar transparencia sobre el objetivo.

Así el Development Team focaliza sus esfuerzos. Lo utiliza para verificar que los PBIs terminados forman parte del objetivo definido.

Antes de comenzar con la demostración del producto, se realiza un breve resumen de qué PBIs se han realizado para lograr el objetivo, así como los distintos incidentes que se han producido a lo largo del sprint: bloqueos, riesgos, incidencias, …

También se debe indicar la velocidad que ha llevado el equipo y se muestra la gráfica burndown donde se ve cómo se ha ido “quemando” el trabajo por hacer.

Burndown

Burndown

La estimación del desarrollo de tareas complejas es difícil de realizar, porque depende de diferentes factores y esto hace que la velocidad en cada interacción varíe. Es importante conocer la velocidad del equipo, y hacer una estimación. Con esta herramienta podríamos tener una predicción de cuándo podríamos entregar en el futuro cierta funcionalidad. Para ello, será necesario tener una estimación de los PBIs en el product backlog.

Tras el resumen, el devteam muestra el incremento y se inicia un debate acerca de los PBIs para ver si es lo esperado en cada caso. Para lograr estar alineados con los stakeholders, llevamos a cabo refinamientos previos.

Por norma (y todos los stakeholders sin excepción), una vez que se ha presentado, la pregunta es “¿para cuándo lo tenemos en producción?”. Esto inicia un debate en el que se obtiene información sobre posibles consecuencias de no tener la nueva versión en producción, y en base a lo obtenido, el product owner determina cuándo sería el mejor momento.

5. El feedback del stakeholder

Este es el punto más importante de todo el Sprint Review. Los stakeholder tienen la oportunidad de exponer sus conclusiones ante el incremento realizado hasta ahora, y todas los nuevos requerimientos y necesidades que tienen. Podrán:

  • Comentar situaciones del producto entregado que no funcionan como se esperaba.
  • Aportar requerimientos que no tenemos contempladas en el backlog.
  • Revisar requerimientos que ya existen en el backlog y que desean actualizar.
  • Exponer prioridades entre las distintas funcionalidades.

En este momento, los stakeholders deberían exponer sus necesidades y el Product Owner tomaría nota de cada una de ellas.

Feedback recibido sobre ideas de mejora del producto.

Feedback recibido sobre ideas de mejora del producto.

Puede darse la situación en la que haya diferentes stakeholders con intereses encontrados. El Product Owner es quien va a resolver la situación informando del valor que se entrega si se resuelve en favor de cada uno o de ambos. A través del diálogo, se va a transparentar cuál va a ser la estrategia a seguir e intentar consensuar una idea de posible objetivo para la entrega de valor del siguiente sprint.

Con las discusiones anteriores, hemos llevado a cabo los puntos:

  • Recoger feedback de todos los invitados a la review (stakeholders y Scrum Team).
  • Revisión del product backlog entre todos y colaborar para determinar qué podría ser lo siguiente a desarrollar.
  • Revisión de cuál podría ser el valor en el siguiente incremento, según los cambios del mercado.
Gráfica de velocidad

Gráfica de velocidad

6. Revisión del release plan

Por último, nos queda revisar el release plan y determinar si estamos en disposición de cumplir con los objetivos del mismo. Aunque inicialmente se propone una tentativa de la primera release, en cada sprint review obtenemos feedback. Esta información puede que implique cambios en la tentativa del release plan. Basándonos en las métricas del trabajo entregado por sprint, podremos obtener la métrica de la velocidad media llevada hasta el momento. Para estimar, en mi caso, utilizo los puntos de historia, que me permiten calcular la media de forma directa. Con la estimación de los PBIs de lo que se ha determinado que podría contener la siguiente release, podremos hacer una estimación de la fecha de entrega de la release y de qué es lo que podremos entregar para la siguiente.

Este punto suele producir cierta controversia, pues los stakeholders pretenden obtener todo lo planteado y en el tiempo comprometido inicialmente. Es labor del Product Owner lograr el consenso.

7. Obtener datos sobre entrega de valor

Uno de los KVIs (Key Value Indicator) que nos permiten conocer el valor entregado es la satisfacción del cliente por lo que recogemos el valor emocional del producto. Para ello, al final del evento, guardamos el grado de satisfacción con tres posibles medidas:

  • Vamos por buen camino.
  • Algo no te cuadra pero podemos vivir con ello.
  • Nada de lo que veo me convence.
Recopilación del grado de satisfacción.

Recopilación del grado de satisfacción.

Satisfacción del cliente.

Satisfacción del cliente.

8. La importancia de una buena comunicación durante todo el proceso

Para llevar a cabo un Sprint Review, el Product Owner tiene que haber estado en contacto con el devteam para conocer de primera mano todo lo ocurrido durante el sprint y así resolver cualquier pregunta de los stakeholders y explicar la motivación de la toma de decisiones que ha realizado en este tiempo. Una buena línea de comunicación ayuda al Scrum Team a tener la información necesaria para realizar el Sprint Review.

El Product Owner no puede comprometerse con las peticiones de los stakeholders sin tener conversaciones previas con el devteam. Este podrá estimar los PBIs, teniendo en cuenta factores como la velocidad llevada para implementar las tareas anteriores. El Product Owner podrá estimar cuándo podría liberar las peticiones en las releases planificadas y evitar compromisos innecesarios. Tiene que hacer una buena gestión de las expectativas de los stakeholders.

9. Recogida de feedback del propio evento

Al finalizar el Sprint Review es una buena práctica recoger feedback del evento realizado, igual que lo hacemos con el incremento entregado. El primero nos permite conocer si el evento contiene los espacios que esperan los presentes, así como darles la oportunidad de proponer nuevas opciones. El segundo, ya comentado en párrafos anteriores, nos sirve para conocer el grado de satisfacción de los stakeholders y así ver el alineamiento existente entre el Product Owner y los stakeholders. Ambos feedback proporcionan información de cómo ha sido el Sprint Review.

Es necesario tener información de los stakeholders para conocer si los incrementos de valor del producto son los esperados, y poder inspeccionar y adaptar sus necesidades. El Sprint Review es el evento en el que podremos transparentar cómo hemos ido desarrollando el producto y conocer los impedimentos o riesgos que pongan trabas al desarrollo, o también, actualizar el product backlog con nuevas necesidades que dan mayor valor a dicho producto.

Fuente de la imagen principal: Unsplash

¿Quieres saber que más cosas hacemos en BBVA Next Technologies?

Utilizamos cookies propias y de terceros para mejorar nuestros servicios, brindarle una grata experiencia y mostrar a los usuarios publicidad relacionada con sus preferencias mediante el análisis de sus hábitos de navegación. Si continúa navegando por este sitio web, consideramos que acepta su uso. Puede cambiar la configuración u obtener más información accediendo a nuestra política de cookies aquí.