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:

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.

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:

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.

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.

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.