Reuniones en Scrum

por Antonio Martel

Dentro de la metodología Scrum se establecen una serie de reuniones con nombres algo complicados y duración, asistentes y fechas prefijadas. Les explico en este post el significado de estas reuniones y, sobre todo, cómo pueden ayudarte en tu trabajo:

Reunión de planificación del trabajo

Antes de comenzar el trabajo previsto para las próximas 2 semanas te reunirás con el cliente (o representante del mismo y con las personas que éste considere) y definirán qué tareas se realizarán durante esas dos semanas (si el equipo de trabajo considera que puede hacerlas en ese tiempo) Durante esa reunión el cliente dará toda la información necesaria sobre las tareas escogidas explicándolas al equipo que va a desarrollarlas.

Tener en cuenta la capacidad de trabajo del equipo durante esta reunión de planificación permite, entre otras cosas, encajar los periodos de vacaciones o las ausencias de los miembros del equipo. Es tan sencillo como explicar ‘Dentro de dos semanas nos comprometemos a entregar solo 3 de estas tareas en lugar de las 5 habituales. Alberto y Pilar tienen vacaciones la próxima semana’ Esto no suele suponer un problema ya que el cliente lleva recibiendo entregas del trabajo cada dos semanas de forma consistente.

Reuniones diarias

El equipo de trabajo y el Scrum Master se reunirán cada día, mejor al inicio de la mañana, durante 15 minutos para contestar a las siguientes preguntas:

• ¿Qué se hizo desde la última reunión?
• ¿Qué se hará desde ahora y hasta la próxima reunión?
• ¿Qué está impidiendo hacer el trabajo lo mejor posible?

Ejerzo habitualmente de Scrum Master en varios proyectos y a cada una de las reuniones diarias llevo una hoja impresa con estas tres preguntas donde mantengo registros de las respuestas del equipo de trabajo. Al final de cada una de estas hojas he añadido un apartado adicional llamado ‘Tareas para el Scrum Master’ y en él anoto todas las cosas que el equipo de trabajo necesita para continuar o qué les está dificultando el trabajo. Anotaciones frecuentes son: ‘Llamar al cliente y pedir lista de usuarios (¡mañana comenzamos con esa tarea!)’ o ‘Pedir exportación de la base de datos (necesitamos una copia ya antes de empezar a modificar datos)’) Es habitual que me pase el resto de la mañana intentado resolver los problemas que me han contado a primera hora.

Reunión de demo

Al finalizar cada iteración de dos semanas se concreta una fecha de reunión con el cliente y se le hace una demostración del trabajo realizado en esas dos semanas. En esta reunión el representante del cliente, en su función como director del proyecto, revisará lo que se le está mostrando y dará su visto bueno o no a lo que ha visto.

Para poder cerrar la funcionalidad es importante que esté completamente terminada y libre de errores (serán necesarias las pruebas del equipo de trabajo y una validación completa del cliente). Si no fuese así, se llegaría al final del proyecto según la gráfica burndown (todas las tareas estarían a 0 horas de trabajo pendiente) pero el proyecto aún no está finalizado porque hay funcionalidades incompletas o con errores por corregir.

Estas entregas periódicas permiten ver al cliente cómo va avanzando su producto, qué se ha estado haciendo durante esas dos semanas y decidir luego, en la reunión de planificación, qué quiere ver en la siguiente reunión de demo. Esto permite ganar confianza ante el cliente que no pierde de vista a la empresa desarrolladora una vez ha terminado la toma de requisitos para volverla a ver meses después con un producto ya completado sobre el que tiene pocas posibilidades de modificación.

Reuniones de retrospectiva

Después de cada iteración de 2 semanas y una vez realizada la demo al cliente, el Scrum Master y el equipo de trabajo se reúnen para estudiar los problemas que han podido ocurrir en esas dos semanas, por qué la demo no salió todo lo bien que debería (o sí) y si se puede hacer algo para mejorar en la próxima entrega.

Es bueno que el equipo de trabajo se sienta libre de expresar lo que considera que han sido los principales problemas aunque eso te haga subir los colores. Los problemas a veces están en la ‘zona ciega’ del Scrum Master y la visión en conjunto ayudará a aportar luz al problema.