Que tu Sprint Review no sea una Demo

En muchas empresas que utilizan Scrum llaman erróneamente Demo al Sprint Review.

Yo no puedo abstraerme de mi background de coaching (ontológico) y por eso le presto, a veces demasiada, atención a las palabras utilizadas. Porque no creo que sea solo una cuestión de terminología.

El Sprint Review es el evento de Scrum clave para el éxito del producto. No se trata de una "demo" donde los developer muestran lo que hicieron, es una inspección del Sprint completado, el incremento de producto, el product backlog y la performance del producto en producción (esto último lo agrego yo).

Muchas empresas desaprovechan el poder creativo de Scrum y los stakeholders asisten solo a una demostración para asegurarse que se hizo lo prometido y luego todos se van a seguir con lo suyo.

De resolver problemas de los usuarios, aprender, adaptar... ni hablemos.

Acá te dejo unos consejos para que un Sprint Review no sea una demo intrascendente y se convierta en el motor para que tu producto sea tan alucinante como te mereces.

Agenda de Sprint Review

1. ¿Para qué?

Comienza compartiendo el objetivo de la reunión. En este caso, inspeccionar el resultado del Sprint y determinar futuras adaptaciones.

💡 por lo general las personas olvidan esta segunda parte y creen que solo vienen a ver qué se hizo.

2. Ver lo mismo

El PO presenta el Objetivo de Sprint y los developers el Definition of Done utilizado durante el Sprint para que todos estén viendo la misma película 🎥.

3. Expectativas

El PO presenta un resumen sobre qué se hizo y qué no se hizo durante el Sprint y recuerda cómo cada PBI a presentar está relacionado al objetivo del Sprint 🎯.

4. Empatía

El Scrum Master presenta cuáles fueron los desafíos 🔥 y aprendizajes 💡 a los que el equipo se enfrentó durante este periodo de tiempo.

5. Uso

Los stakeholders utilizan el Incremento 🛠️ creado por el Equipo Scrum, no solo miran pantallas. Proporcionan feedback que cualquier miembro del Equipo Scrum va registrando. Cualquier persona puede sugerir mejoras a partir de la observación de uso del Incremento.

6. Más allá

Siempre insisto que los equipos de producto deben ir más allá de lo que plantea Scrum y revisar conjuntamente los outcomes en producción (principalmente datos cuantitativos).

Por ejemplo: conversion rate, churn rate, lifetime customer value, etc.

7. Cómo seguir

Basándose en el feedback identificado y en los insights de los datos se discuten y determinan modificaciones al Product Backlog a partir del feedback relevado.

8. Cierre

Se realiza una breve retrospectiva sobre esta Sprint Review en busca de mejoras a futuro.

En definitiva

Los Scrum Masters avanzados tienen la capacidad de hacer de las reuniones de Scrum eventos que van mucho más allá y se nota la diferencia a millas de distancia.

Guárdate este post para tenerlo a mano cuando más lo necesites 😉.