La receta para conseguir un buen Sprint Review

El Sprint Review es el meeting de negocio por excelencia. Durante el mismo se pone de manifiesto la transparencia en torno al incremento, se inspecciona y se adapta el Product Backlog.El Sprint Review es la oportunidad para que todos los Stakeholders, incluido el propio equipo Scrum, inspeccionen el incremento terminado durante el Sprint. Para ello es importante, además de invitar a los Stakeholders para promover la transparencia, tener claras cuales son las condiciones actuales de negocio y el Product Backlog, para poder actualizarlo al terminar la Review. La Sprint Review se organiza y coordina por el Product Owner
, no por el Scrum Master ni el Development Team.

Ingredientes para el Sprint Review

• El equipo Scrum
• Un Incremento terminado (que cumpla la Definition of Done)
• El Sprint Backlog
• El Product Backlog
• Las condiciones actualizadas del negocio.
• Un puñado de Stakeholders.

Y el resultado es:

• Un Product Backlog actualizado con el feedback de Stakeholders

Si los Stakeholders no acuden a el Sprint Review, entonces se pierde la transparencia, especialmente si estos necesitan de «reuniones» y «reportes» especiales. La interacción entre los Stakeholders y el equipo Scrum es fundamental para que ambos tengan una sensación adecuada de cómo van las cosas.

El Sprint Review no es una demo

En ocasiones, el Sprint Review se convierte en una «demo» e incluso se le llama así. Esta es una señal de una manera bastante pobre de hacer Scrum. Muy pobre. El Sprint Review tiene dos objetivos: Inspeccionar el incremento terminado y adaptar el Product Backlog.

Para cumplir estos objetivos se revisa el Sprint Backlog y se muestra el producto, dando la oportunidad a las partes interesadas de poner en cuestión y preguntar lo que deseen sobre el mismo. También se da información sobre condiciones que pudieran afectar a los objetivos del negocio o del producto. En ocasiones, el Product Owner hace una reunión de pre-planning o similar con los Stakeholders. Esta reunión no sirve a la transparencia, pata fundamental de Scrum.

Tampoco es el momento de aplaudir al equipo de desarrollo. El concepto de aplaudir va asociado a un buen trabajo, y a pesar de que puede dar la sensación de que es la manera de dar feedback al equipo Scrum, no es la más adecuada. El motivo es que esta es una reunión de trabajo, no una demostración del trabajo. La mejor manera de retroalimentar al equipo es mediante el feedback sobre el Incremento y el Product Backlog.

Si hoy aplaudo… ¿Quiere decir que mañana puedo abuchear?.

El Sprint Review no es el momento de aceptar Product Backlog Ítems terminados

Otras dos señales de una manera pobre de hacer Scrum son cuando el Product Owner «acepta» los PBIs terminados en el Sprint Review. Esto puede indicar falta de colaboración entre el equipo Scrum -o «Product Owner ausente»- o que el equipo trabaja en todas las tareas del Sprint Backlog a la vez, creando un burndown plano con una caída el último día del Sprint. Estos equipos probablemente son principiantes en Scrum y todavía tienen problemas de colaboración y comunicación entre ellos.

El Product Owner debe de ir inspeccionando y aceptando ítems durante todo el Sprint y, por tanto, conocer de primera mano como es el Incremento. Al contrario, el Product Owner ES la persona responsable de mostrar el incremento durante el Sprint Review a los Stakeholders y rendir cuentas por sus decisiones.

El Sprint Review es el momento de actualizar información del negocio

Algunas organizaciones están implementando reuniones especificas -tipo all-hands– para informar a todo el mundo de las condiciones de negocio actualizadas. Durante el Sprint Review es un momento perfecto para esta operación. Todos los Stakeholders juntos. Los equipos Scrum. ¿Qué mejor?

Es importante hacer una actualización de las condiciones de negocio (competencia, market share, profitability, etc..) durante esta reunión para poder proceder a adaptar el Product Backlog a la vista de todos, con la información que tiene el Product Owner. El principal impedimento en estos casos es la reticencia a ser transparente, ya que esta operación deja muy poco margen para la política corporativa de pasillo, obligando a los implicados a retratarse frente al resto de compañeros. Así es cómo debe ser. Así es como Scrum funciona.

Si Scrum tiene que ser reducido a una sola cosa, esta es entregar un incremento terminado cada Sprint, y en esto el Sprint Review juega un papel fundamental.