Reunión diaria de Scrum

Reunión diaria de Scrum, ¿preparada o improvisada?


La reunión diaria o daily meeting es una reunión de los equipos Scrum que se realiza todos los días a la misma hora y lugar, cuyo objetivo principal es coordinarse para conseguir el objetivo del Sprint. En ella cada miembro del equipo explica que hizo ayer y que piensa hacer hoy para acercar al equipo a dicho objetivo, y sobre todo si existe algo que por la razón que sea impide llegar a ese objetivo.

En la mayoría de literatura ágil da a entender o directamente indica que se trata de una reunión improvisada. La realidad es que para que la reunión diaria sea lo que se supone que es, ágil, es conveniente prepararla con antelación para no entretenerse y desenfocarse demasiado durante la reunión.

Al fin y al cabo se trata de una reunión y como tal se tiene que preparar. No queremos por ejemplo perder tiempo preguntando si el tablero Kanban está actualizado ni abriendo Outlook para ver cuándo es la próxima demo.

En mi opinión, el responsable principal de la preparación es el Scrum Master, que es el encargado de facilitarla y asegurarse de que es productiva.

Principales puntos a preparar en la reunión diaria de Scrum

Los puntos principales a preparar antes de cualquier reunión diaria por parte del Scrum Master son los siguientes:

¿El tablero Kanban o Scrum con sus historias está actualizado?

Si vemos que hay tareas que no se han transicionado a su estado actual (tareas listas para testing, o ya realizadas) es un buen momento para actualizarlas. Por lo general, son los mismos desarrolladores los que deben mover las tareas de un estado a otro, pero es común que por muchos motivos se les puedan pasar. Mejor que parar la reunión para actualizarlas al momento y dejarlo en evidencia delante del equipo, es actualizarlo y decírselo en privado para que la próxima vez no se le olvide.

¿Hay historias de usuario bloqueadas?

Es muy probable que hayan historias de usuario pendientes de validación, de maquetas, de la intervención de un tercero, de que nos respondan un mail, o mil cosas más que no están dentro del equipo. Por muy multidisciplinar que sea el equipo, es común encontrar bloqueos, por lo que es necesario identificarlos rápido para actuar en consecuencia. Si existe alguna historia en este estado estamos ante un impedimento, y hay que alzarlo en la reunión para que alguien tome la responsabilidad de desatascarlo.

¿Hay algún cuello de botella preocupante en el equipo?

Un cuello de botella no es algo malo, sino algo inevitable. Cualquier sistema por definición tiene un cuello de botella. Si el cuello de botella del equipo se puede convertir en un problema para el objetivo del Sprint, quizás se puede decidir algo que ayude a mitigarlo. Si tenemos un cuello de botella en QA, es razonable plantear en la reunión si algún desarrollador puede echar una mano.

Comprobar Information Radiators

Echar un vistazo a los principales information radiators, por ejemplo a los Burndowns de Sprint o de proyecto y al diagrama de flujo acumulado. ¿Cómo vamos en el proyecto, Sprint o Release? Si estamos cerca de un final de Sprint o de una fecha de entrega, es conveniente preguntarnos si podemos priorizar alguna historia para cerrrarla antes de comenzar nuevas que sabemos que no van a entrar en esa entrega.

¿Es necesario preparar algo para la demo?

Las demos son como los partidos de los futbolistas profesionales, te pasas la semana entrenando para preparar el partido del fin de semana. En Scrum lo equivalente es pasarte toda la semana currando para después hacerlo muy bien en la demo, que luzca. Por eso es muy importante prepararla bien, asegurarse que lo que va a salir en la demo está bien probado. Recomiendo siempre nombrar a un responsable de demo que sea el encargado de preparar el guion completo y a prueba de bombas para no dejar nada al azar.

¿Hay reuniones del equipo a la vista?

Seguro que hay más reuniones durante la semana, planning pokers, groomings, retrospectivas, etc. ¿Están correctamente planificadas y preparadas? Algunas son responsabilidad del Scrum Master como las retrospectivas, pero otras como los groomings o los planning pokers exigen un trabajo previo por parte de los desarrolladores (pruebas de concepto, validaciones técnicas, etc.)

Conclusiones

Por supuesto que el Scrum Master no es el encargado de resolver todos los puntos ni conflictos indicados en el listado superior, pero sí es el responsable de que salgan a la luz y hacerlos evidentes al equipo para que entre todos encontremos la mejor manera de solventarlos planificada y ordenadamente.

Es cierto que a medida que el equipo va madurando, poco a poco este trabajo previo se irá reduciendo y disgregando. De todas formas siempre debería haber una preparación para que la reunión diaria sea muy rápida y enfocada a resolver los impedimentos y coordinar acciones entre el equipo para funcionar de la mejor manera.

La preparación de esta reunión por parte del Scrum Master será una inversión en lugar de una pérdida de tiempo. Solo teniendo en cuenta que a la reunión va todo el equipo, el tiempo ahorrado en la reunión por temas que no aportan compensará el tiempo previo que le deba dedicarle el Scrum Master. Teniendo en cuenta también que normalmente la reunión diaria se hace a primera hora de la mañana, conviene que el Scrum Master sea madrugador, pero eso ya es un tema que da para otro post :-)

También te puede interesar...

Meetup “Los secretos para una daily de pena&... ¿Es suficiente con responder a las 3 preguntas para tener una daily efectiva? ¿Crees que las dailies no aportan valor? ¿Piensas “uff otra vez da...
Resumen User Stories Applied de Mike Cohn ¿Qué es una historia de usuario?¿qué elementos debe cumplir?¿cómo se crean? El libro User Stories Applied de Mike Cohn nos da respuesta a éstas y c...
Resumen Lean Software Development El libro Lean Software Development de Mary y Tom Poppendieck es una lectura obligatoria para todos aquellos que quieran entender muchos de los princip...

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Una idea sobre “Reunión diaria de Scrum, ¿preparada o improvisada?