Daily Scrum (Scrum Diario)

¿Qué es la Daily Scrum?

La Daily Scrum es una reunión con un timebox o duración máxima de 15 minutos, en la que los desarrolladores inspeccionan el avance desde la Daily anterior y planifica las siguientes 24 horas de trabajo. Sus características básicas son:

  • Su finalidad es evaluar el progreso hacia la consecución del Objetivo del Sprint o Sprint Goal y adaptar el Sprint Backlog en consecuencia. Fomenta la colaboración y la pronta identificación de impedimentos, aumentado así las posibilidades de cumplir con dicho Objetivo.
  • Es una reunión interna por y para los desarrolladores del Equipo Scrum, dirigida por estos.
  • El Scrum Master se asegura, no obstante, de que la reunión se lleve a cabo, dentro del timebox, y de que su propósito sea entendido.
  • Si el Scrum Master o el Product Owner también estuvieran trabajando en elementos del Sprint Backlog, participan en la Daily como Desarrolladores. De lo contrario, no tienen que participar en la reunión (o no deben).
  • Se realiza todos los días, preferentemente a la misma hora y en el mismo sitio, para simplificar.
  • Tradicionalmente, los desarrolladores han utilizado tres preguntas para estructurar la Daily: ¿Qué hice ayer para ayudar a lograr el Objetivo del Sprint? ¿Qué haré hoy para ayudar a lograr el Objetivo del Sprint? ¿Detecto algún impedimento que evite que logremos el Objetivo del Sprint?
  • Estas tres preguntas, que la Guía Scrum 2017 mencionaba a titulo ejemplificativo, ya ni siquiera se incluyen en la Guía Scrum 2020. Este cambio se debe al uso monótono y viciado de las preguntas, que nunca fue obligatorio, sino opcional. Por ejemplo, los desarrolladores podrían decidir utilizar una única pregunta para todos: ¿por qué el elemento más importante de los seleccionados para este Sprint aún no está terminado?
  • Aunque puede ser una buena práctica, popularizada por el Extreme Programming, no tiene por qué realizarse de pie (standing up).
  • El Scrum Diario no es el único momento en el que los Desarrolladores pueden ajustar su plan de trabajo. Lo habitual es que se reúnan a lo largo del día para tener conversaciones más en detalle, o para replanificar el trabajo según sea necesario.

¿Para qué sirve la Daily Scrum?

Entre las ventajas del Scrum Diario, cabe destacar las siguientes:

  • Crea “presión” entre iguales. Los Desarrolladores se comprometen con el Objetivo del Sprint, y trabajan de forma interdependiente para conseguirlo. Si alguien dice durante varios días seguidos que va a terminar una determinada tarea y no lo hace, resultará obvio.    
  • Permite una coordinación detallada entre los Desarrolladores, que saben cuándo uno va a empezar o terminar una determinada tarea, a fin de minimizar tiempos de espera y gestionar dependencias.
  • Pone el foco en las tareas más importantes que han de ser terminadas, con objeto de minimizar el trabajo en curso y acercarnos progresivamente al Objetivo del Sprint.
  • Refuerza el compromiso diario de cada cual con el resto del Equipo y el Objetivo del Sprint.
  • Sirve para la exposición de impedimentos, si los hubiera.

Problemas de la Daily Scrum y estrategias de mejora

¿De qué problemas suele adolecer el Scrum Diario y cómo podemos intentar mejorarlo? A continuación, hacemos un repaso de las “patologías comunes” y ofrecemos sugerencias para paliarlas.


1/ La Daily Scrum se ha convertido en un “reporte” al Scrum Master, que pasa lista a las tropas. “Menganito, ¿qué hiciste ayer y qué vas a hacer hoy? ¿Algún obstáculo? Fulanito, te toca”. Los Desarrolladores no colaboran entre sí, ni tan siquiera se miran, sino que dan el parte correspondiente al Scrum Master, Generalísimo de Scrum. Todos hemos estado en este tipo de Daily. O bien la hemos sufrido o bien, inocentemente, la hemos alentado o “protagonizado”. El Scrum Master, como buen servant leader, no tiene que ser el protagonista de nada. Es, como decíamos, una reunión por y para los Desarrolladores.

En parte, este problema tiene su origen en las tres preguntas “tipo” que la Guía Scrum sugería, que fueron “pervertidas” para desplazar el foco y la responsabilidad hacia cada individuo, en lugar de hacia los Desarrolladores en su conjunto. Las tres “preguntitas” pueden llevarnos a un Scrum mecanizado, nada dinámico. La nueva Guía Scrum ha suprimido de cuajo esta mención y, con suerte, ello contribuirá a que los Equipos incurran menos en esta situación.

Planteamos tres posibles estrategias a probar en este escenario:

  • Insistimos: las tres célebres preguntas nunca han sido de obligado seguimiento. Puedes probar a eliminar las preguntas por completo. En su lugar, podéis comentar los elementos del Product Backlog y su progreso (tareas, blockers, dependencias, etc.), utilizando un tablero Scrum físico, o virtual en estos tiempos de Covid-19.
  • Otra opción es cambiar las preguntas con otras que fomenten más la colaboración, a saber: ¿Qué es lo más importante que debemos hacer hoy? ¿Alguien necesita ayuda?  
  • Vete de la Daily. Si eres el Scrum Master y llegas a la conclusión de que  eres el problema, considera no asistir al Scrum Diario. No, tu participación es este evento no es obligatoria. O al menos apártate a un segundo plano (o pon tu cámara en off y micro en mute) y deja que los Desarrolladores procedan como mejor consideren. Contente, no interfieras, todo irá bien. 

2/ El timebox de 15 minutos no se respeta. Otro clásico. La gente se enrolla y se va “por los cerros de Úbeda”, sin hablar de las tareas en curso, ni mucho menos del Objetivo del Sprint. Recuerdo un proyecto en el que el Scrum Master, que también era el CTO, utilizaba la stand-up como “reunión social”, en la que gastar bromas, si era lunes preguntar a los Desarrolladores cómo había ido el fin de semana… La Daily solía durar media hora, a veces se alargaba hasta la hora. Aquello era insufrible.

Algunos aspectos a valorar en estas situaciones son:

  • ¿Entendemos la finalidad del Scrum Diario? Un buen recordatorio se antoja necesario.
  • Prueba a utilizar algún cronómetro visual.
  • Prueba con algún objeto físico que los compañeros se vayan pasando. Me gusta mucho este yellow chicken (en la imagen superior), que además suena al apretarlo. Quien tiene el chicken tiene la palabra.
  • Si estamos teniendo conversaciones sobre detalles técnicos o funcionales durante la Daily, mejor desgajarlas, aplazarlas para justo después de la reunión. Que los “implicados” en las tareas en cuestión hablen todo lo que tengan que hablar, pero sin lastrar la Daily.
  • ¿Tenemos el número adecuado de Desarrolladores? A veces el Scrum Diario se alarga simplemente porque tenemos a demasiada gente en el Equipo.

3/ La Daily no se hace todos los días. En una ocasión coincidí con una Scrum Master que me decía que le gustaba hacer la Daily Scrum en días alternos, o sea, un día sí y un día no. Le pregunté que por qué razón, y simplemente me dijo que ella lo prefería así… ¡Pero vamos a ver! El Scrum DIARIO se hace todos los días, no cuando al Scrum Master le apetezca. De lo contrario, nos dejamos ir a la deriva, sin actualizar nuestro plan de trabajo DIARIO y poner de relieve posibles impedimentos.

Y, sí, la Daily también se hace el día después de la cena de Navidad…


4/ Algunos Desarrolladores llegan tarde o no asisten. La falta de puntualidad (y peor aún, el no show) son faltas de respeto hacia el resto de compañeros, siendo respect justamente uno de los valores que Scrum propugna. Si alguna vez habéis recurrido a la “hucha de las vergüenzas” (50 céntimos o lo que toque cada vez que alguien llegue tarde) o a métodos similares de reprimenda, habréis comprobado su escasa o nula eficacia.

Algunos aspectos a cuestionarse aquí:

  • ¿Han sido los Desarrolladores quienes han acordado la hora en la que se hace el Scrum Diario, o ha sido, en realidad, impuesta por algunos de sus miembros o por el Scrum Master?
  • ¿Hemos puesto en común, como equipo, los valores Scrum? ¿Entendemos su significado?
  • Si la falta de puntualidad o asistencia solo se refiere a miembros aislados, ¿existe algún problema personal que este afectando a nuestro compañero?

5/ No todos los Desarrolladores participan o se atreven a comentar posibles impedimentos, o algunos se distraen o desconectan de la reunión. Puede que algunos compañeros sean excesivamente escuetos, o que no se atrevan a hablar, o que sencillamente algunos “levanten la voz” más que otros y acaparen la reunión, o que algunos se distraigan más de lo deseable… Todo ello se traducirá en una menor transparencia a la hora de evaluar el progreso diario y en una menor coordinación.

En estos casos, algunas ideas a probar pueden ser:

  • Utilizar el yellow chicken mencionado más arriba.
  • Hacer una dinámica de Fist of Five Voting, que permite al Equipo hacer votaciones de 1 a 5 sobre cuestiones diversas, ayudando a disentir de un modo “elegante”.

6/ Problemas de logística o con la tecnología. En un proyecto, teníamos al Equipo trabajando desde dos oficinas, cada una en una ciudad. Empezamos a hacer la stand-up a través de Skype, con un solo portátil “a cada lado”. Además, los compañeros de la otra ciudad siempre tenían problemas reservando la sala para reuniones. El resultado era catastrófico: se empezaba tarde, costaba escuchar las intervenciones, el timebox no siempre se respetaba… En lugar de ser una reunión colaborativa y valiosa, se convirtió en un trámite arduo que nada aportaba.

En estos escenarios, en fin, se trata de encontrar una buena herramienta, que esta crisis del coronavirus ha servido para demostrar que las hay, en abundancia; y, sobre todo, de utilizarlas con sentido común. Personalmente, en las reuniones telemáticas prefiero que cada uno esté delante de su ordenador, en condiciones de igualdad, antes que tener “grupetes” en torno a una misma pantalla.


7/ Product Owner, managers o stakeholders que sabotean la reunión. El Scrum Diario no es para el Product Owner, que hará bien en no participar. Tampoco para otros stakeholders, que de estar presentes deberían no interferir en la reunión. Si “agentes externos” torpedean la Daily, los propios Desarrolladores o el Scrum Master tendrán que invitarles, cariñosamente, a que no molesten.


< Volver a Scrum