Al finalizar el sprint se realiza una revisión de lo entregado en el sprint para poder ver lo que se ha estado haciendo durante el mismo y tener la oportunidad de adaptarse si hubiese que hacer algún cambio. No se trata de una reunión de seguimiento en la que se va a juzgar al equipo de desarrollo sino de tener la posibilidad de presentar el trabajo y comprobar cómo de cerca o de lejos estamos del objetivo y si necesitamos hacer cambios para que el producto esté más orientado a las necesidades del cliente.
El tiempo máximo establecido para esta reunión de demo o presentación del trabajo del sprint es de 4 horas para sprints es de un mes o la mitad si el sprint es de sólo dos semanas. Es trabajo del Scrum Master el que la reunión se lleve a cabo y se mantenga dentro de los tiempos establecidos.
A esta reunión de demo asistirán el Scrum Master, el Dueño del Producto, el equipo de trabajo y los interesados que el Dueño del Producto invite a la reunión y en ella se explicarán qué elementos de la pila del producto se han terminado y cuales no para poder acabarlos. Tras esto el equipo de desarrollo demostrará ante todos los asistentes cómo funcionan los elementos terminados de la lista del sprint.
Esta reunión servirá para que el cliente pueda ver cómo se han desarrollado los requisitos que ha dado, si se están entendiendo estos requisitos, sus objetivos generales para el producto y comprobar si se cumplen sus objetivos. El equipo, desde su punto de vista, puede comprobar si realmente está entendiendo estos requisitos y mejorar la comunicación con el cliente. Estas reuniones en las que se presenta el producto poco a poco servirán para ir entregando el trabajo e ir obteniendo feedback del mismo sin esperar meses y meses antes de presentarlo al cliente que podría no estar contento con las decisiones tomadas en todo ese tiempo.
Algunos de los problemas más habituales de las reuniones de demo del sprint son:
Demos indemostrables
Habrá ocasiones en las que los miembros del equipo de desarrollo pueden pensar que no tienen nada que mostrar en esta reunión de demo o que lo que han hecho en este sprint no tiene una interfaz gráfica que pueda ser mostrada. En casos como estos deberemos buscar una demo mínima que pueda presentarse.
Por ejemplo, si tenemos una funcionalidad que se trata de montar el entorno de desarrollo para poder comenzar a trabajar, en la reunión de demo mostraremos el Eclipse funcionando con el jetty configurado para las pruebas, el cliente de Subversion instalado y la herramienta de conexión a la base de datos correctamente configurada para establecer la conexión.
Si tenemos otra tarjeta que nos indica que debemos montar una estructura de tablas de bases de datos y sus relaciones podremos crear una página Hello World mínima que se conecte a esta base de datos y muestre un listado de las tablas que acabamos de crear.
Demos vacías
Hacemos demos pero en estas se muestran sólo powerpoints y no trabajo real que demuestre que no estaremos avanzando a través de los sprints y cuando alcanzamos el final del proyecto nada funciona, los módulos no están bien integrados entre sí y nada pinta tan bien como lo hacían en los powerpoint.
Deberemos mostrar trabajo real en las demos que presenten lo que se ha estado haciendo. Los powerpoint están prohibidos en estas presentaciones. Será necesario buscar la manera de presentar nuestro trabajo y que sea éste el verdadero valor de lo que estamos haciendo.
Temor a las demos
A veces el equipo de trabajo acude con miedo estas demos. Va a estar el cliente, el dueño del producto, quizás más representantes del cliente y no hemos terminado todos las funcionalidades previstas para el sprint, o lo que es peor, algo puede fallar en la presentación y verse mal. Bueno, no pasa nada, la reunión de demo no es una reunión de seguimiento, se trata de mantener una reunión intencionalmente informal.
Se mantiene esta reunión cada poco tiempo para que no haya grandes dramas o grandes sorpresas en ellas. Se trata de tomarle el pulso al proyecto y ver cómo va, no de apretarle las tuercas al equipo de desarrollo. Si algo salió mal en la reunión de demo será nuestra prioridad en el siguiente sprint y como seguramente sólo será la corrección de un bug podremos sumar puntos fácilmente en la reunión de demo del siguiente sprint.
Si las cosas salen mal repetidamente en las reuniones de demo o muchas funcionalidades previstas para el sprint quedan marcadas como no terminadas porque no pasan los tests, deberemos reducir la carga de trabajo prevista para nuestros sprints. Nuestra velocidad está siendo más baja de lo que pensábamos y necesitamos algo más de tiempo para que más cosas sí queden bien terminadas en la reunión de demo.
