Review del Sprint

Finalidad y duración

El Scrum Teams da transparencia al Incremento y puede inspeccionar el Product Backlog (PB) para adaptarlo, junto a los stakeholders2, en función de las necesidades de mercado y del feedback recibido. Es decir, no es una demo: en una demostración sólo se inspecciona y en este evento se realiza inspección sobre el incremento para adaptar el PB. Scrum trata de maximizar el valor del producto y la Sprint Review es el momento de comprobar si lo estamos consiguiendo y donde el que el equipo Scrum y los stakeholders se unen para discutir qué hacer a continuación. Duración: Máximo cuatro (4) horas para un Sprint de un mes (aproximadamente 1 hora por cada semana de Sprint).

Cuatro aspectos clave

  1. Es fundamental que los stakeholders estén presentes. No todos, sino los más relevantes. De lo contrario 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 distinto al deseado. En el caso de ausencias conocidas y justificadas1 el Product Owner (PO) puede ayudar a recopilar ese feedback e incorporarlo al evento para ponerlo en conocimiento del resto.
  2. Que asista todo el equipo de Scrum, aunque parte de él trabaje a distancia. Pueden aportar información durante el evento y así reciben directamente el feedback de los stakeholders. El PO puede actuar igual que con los stakeholder en caso de ausencias previstas.

    Esto debe ser algo puntual por enfermedad, vacaciones, etc. Si un stakeholder no tiene interés o tiempo debe ser reemplazado porque no sirve como parte interesada. El evento debe formar parte de la agenda rutinaria de las partes implicadas en el producto.

  3. Separar la Sprint Review de la Retrospectiva. Aunque ambos eventos son un momento para la reflexión tienen objetivos y asistentes diferentes.
  4. Es un evento colaborativo e informal. No se trata de un punto de control o seguimiento del equipo, ni una presentación unidireccional. El objetivo es aprender y usar ese aprendizaje para adaptarnos y hacerlo mejor, no se buscan formalidades que puedan retrasar.
    La forma de desarrollarlo es promoviendo la comunicación efectiva y la colaboración entre todas las partes involucradas. Es una sesión de trabajo donde todos los participantes son sujetos activos, no el momento de aplaudir al equipo de desarrollo.
    La mejor manera de retroalimentar al equipo Scrum es mediante el feedback sobre el incremento y sobre el PB.

Posible agenda de la reunión

En esta sesión de trabajo se recomienda tratar los siguientes puntos:

  1. Introducción a la Review
    • Recordar el Objetivo del Producto (PG)
    • Exponer el Sprint Goal (SG) y valorar su cumplimiento
  2. Inspección del Incremento - Recorrer los entregables relacionados con cada impacto incluidos en el Sprint (repetir para cada impacto con entregables):
    • Centrarse en un único impacto a la vez y presentar los entregables correspondientes (PO)
    • Consensuar si los entregables garantizan que se logre el impacto por parte del actor que corresponda (stakeholders y Scrum Team)
  3. Adaptación
    • Revisión del Mapa de Impacto (IM) según los cambios del mercado y el aprendizaje desde la última Review
    • Revisión del PB e identificación de cuál podría ser el valor del siguiente Incremento

Secuencia de la agenda

Preparación antes de la reunión: El PO debe saber en todo momento el estado actual del producto y cómo ha maximizado la entrega de valor durante el último Sprint. Es el más indicado para conducir el evento por lo que debe preparar lo que necesite para guiar la sesión de trabajo (tarjetas de apoyo, PB, SB, IM actualizado, trasparencias, etc…).
Preparar también la demostración: Es un componente central de la Review donde el equipo Scrum muestra el Incremento. Esta demostración se debe centrar en lo que ACTUALMENTE puede lograrse con el producto sin hablar de futuribles o mostrar partes que no estén “done1” (lo cuál sería un indicio para el Scrum Máster de que algo no se está haciendo bien y falta trasparencia). Ya habrá tiempo de tener una visión a futuro cuando llegue el momento de proponer un SG para el próximo Sprint.

  1. Introducción: El PO repasa la “visión” del producto y el PG. Esto nos va a permitir enfocarnos en el objetivo principal, las soluciones que se van a aportar a los usuarios y el valor que les proporciona con ellas.
    Escribirlo en la pizarra junto al SG y dejarlo ahí. No borrar hasta que termine la Review.
    Antes de inspeccionar en detalle el Incremento, el PO hace una valoración acerca del grado de cumplimiento del SG para ponerlo en contexto y captar la atención sobre el valor conseguido y que pueda ser confirmado por todos los participantes durante su inspección.

  2. Inspección del Incremento: Se mostrará el IM1 y se abordará uno por uno los entregables agrupados por impacto. Para cada impacto se verificará qué se aporta de nuevo y se validará con los stakeholders que efectivamente el actor estará afectado como se espera por el impacto. Si la respuesta no es unánime deberá de estudiarse el por qué para completarlo o descartarlo en el caso de que ya no sea un impacto deseado, con lo que podemos tener los siguientes casos:
    • Se ha logrado el impacto deseado con los entregables y sólo queda estimar cuánto contribuye a las métricas del objetivo de negocio para monitorizar y validar el impacto. Esto podría resultar en un nuevo PBI si no estaba ya prevista su medición.
    • El impacto se logra parcialmente y surge nuevo trabajo pendiente que se incorpora al PB. Habrá que valorar si se quieren mantener los entregables parcialmente en el Incremento, si se desea apartarlos hasta que esté completado totalmente o si incluso se planifica una entrega antes de la próxima Review para recibir lo que falta (dependerá del volumen de trabajo que se estime)
    • No se logra el impacto o no es deseado. Este caso debe ser estudiado especialmente por si hay que pivotar, por si no se está consiguiendo una buena comunicación y el producto puede verse afectado, se ha perdido el foco o incluso se ha introducido un valor negativo.
  3. Adaptación del Producto: Éste es el punto más importante de toda la Review de cara al futuro y la planificación.
    Una vez que todos los participantes tienen claro en qué situación está el producto al finalizar este Sprint, se puede adaptar el siguiente trabajo para lo que se tendrá en cuenta lo que se ha aprendido desde la última Review respecto al producto y el mercado:
    • Los stakeholders deben exponer la experiencia que transmite el usuario si no fuera ya conocida por el PO1
    • También la retroalimentación que se está recibiendo desde el negocio por parte de los usuarios/clientes. Pueden ser directos, provenir de comportamiento recibido desde tests A/B, de encuestas o de valoraciones y comentarios en una store por ejemplo.
    • Conocimiento adquirido sobre la competencia o últimas tendencias que puedan afectar a objetivos o calendario de negocio (campañas de temporada, nichos especializados, acciones de marketing, etc…)

    En cualquier caso, hay que contrastar este aprendizaje contra el IM por si es necesario actualizarlo. Una vez actualizado o confirmado hay que ver si el PB sigue siendo válido o actualizarlo igualmente.
    Con el PB actualizado se puede revisar el orden de los PBIs, pero se hará verificando el impacto con el IM, no por cuestión de urgencia o capricho de los asistentes sino buscando que el siguiente incremento aporte el máximo valor con lo que se conoce actualmente.
    Inspeccionando los primeros elementos del PB deberá establecerse una propuesta de SG para el siguiente Sprint. Debe ser una idea general compartida, no se trata de hacer la Sprint Planning, pero sí que todos los participantes se hagan una idea aproximada de qué se puede esperar para la siguiente Review.

Antipatrones

La Sprint review NO es una sesión: