Allá por 2015 escribí una serie de artículos sobre esta reunión y este artículo me quedó a medio escribir en la carpeta de borradores. Ayer por la tarde una consulta de una colega me motivó a completar el borrador y publicarlo. Espero resulte útil.

Las reviews de mis proyectos suelen tener 2 partes a las que suelo denominar PPT y Demo.

La parte de Demo es donde se muestra el resultado del trabajo realizado. En términos de Scrum es el incremento de producto, en términos de desarrollo más genérico es el working software. Algunos puntos importantes: esta demostración del software se hace en un ambiente de Test/QA (o como gusten llamarle) es una ambiente con bastante estabilidad y definitivamente no es la máquina de un developer. Incluso en algún caso muy particular he hecho la demo directamente en el ambiente productivo.  Como mencioné en un artículo anterior, la Demo no puedo fallar pues no hay razón para que fallé: la estamos corriendo en un ambiente controlado, tenemos tiempo para prepararla y definir exactamente el flujo de acciones. Es cierto, puede haber algún imprevisto como que se caiga la red y por eso es que debemos tener un plan B. Dicho plan B puede ser correr la demo en otro ambiente o bien tener la demo grabada en video. Lo que el equipo considere necesario para asegurar poder mostrar el producto funcionando.

Por otro lado está la parte que suelo denominar PPT en referencia a las diapositivas que se suelen utilizar para guiar esta parte de la reunión. En esta parte de la review repasamos el compromiso, comentamos los eventos relevantes ocurridos durante la iteración y vemos algunas métricas. Finalmente cerramos con una sugerencia sobre los siguientes pasos. En algunos casos, dependiendo de la dinámica del proyecto, puede que también repasemos el estado de los riesgos del proyecto. Todas estas cuestiones se traducen en los siguientes slides:

1. Portada: nombre del proyecto, número de iteración, fecha
2. Slide 1: bullets con los hitos relevantes de la iteración y su estado (completo / incompleto)
3. Slide 2: Burdown chart
4. Slide 3: Detalle del backlog
5. Slide 4: Sugerencia de siguientes pasos

Si la iteración incluyó algún entregable que no fuera código (como por ejemplo un spike o algún documento técnico) entonces hay un slide dedicado a esto.

Básicamente considero 3 alternativas para articular estas dos partes:

1. Primero PPT y luego Demo
2. Primero Demo y luego PPT
3. PPT – Demo – PPT

Generalmente utilizo la variante 3.

Dependiendo de la dinámica del proyecto, puede que la demo la ejecute algún developer o directamente el producto owner.