Por qué Sprint Review y no demo
La razón de ser de la de la reunión de revisión del sprint es que el incremento pueda ser examinado. En muchas empresas que utilizan Scrum, es una confusión habitual llamar erróneamente Demo Sprint al Sprint Review. Este evento de Scrum no se trata de una "demo" donde los desarrolladores muestran (o cuentan) a los stakeholders lo que hicieron sino un espacio para inspeccionar el incremento y recibir feedback producto de la interacción con él.
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. Pero no. En la Sprint Review bien hecha los stakeholders utilizan el incremento, no sólo escuchan o ven pantallas. El feedback se da sobre lo experimentado.
Veamos algunas ideas de diseño de agenda para evitar que la Sprint Review se convierta en una demo.
Modelo de agenda
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 Product Owner presenta el Objetivo de Sprint y los developers o desarrolladores el Definition of Done (DoD) utilizado durante el Sprint para que todos estén viendo la misma película.
3. Expectativas
El Product Owner presenta un resumen sobre qué se hizo y qué no se hizo durante el Sprint y recuerda cómo cada Product Backlog Item 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 Scrum se enfrentó durante este periodo de tiempo.
5. Uso
Los stakeholders utilizan el Incremento de Producto 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 de Producto.
6. Más allá
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.
- Filosofía y funcionamiento:Valores y principios, Equipo, desarrollo iterativo e incremental con Sprints, Sprint Backlog, Product Backlog y PBIs, refinamiento, criterios de aceptación, y más.
- El campo de acción del Scrum Master y las cuatro disciplinas de su trabajo cotidiano.
- Las diferencias entre el liderazgo Ágil y el tradicional para adaptarse mejor a los cambios y liderar desde el servicio.
- Estimación Relativa de PBIs o Historias de Usuario, planificación evolutiva de desarrollo ágil de productos digitales y métricas basadas en outcomes.