Daily Standup — qué es, reglas para la reunión diaria y beneficios

¿Qué es el Daily Standup?

Daily Standup — una reunión corta del equipo Scrum que se realiza a la misma hora y en el mismo lugar cada día laborable. Timebox — 15 minutos. Se conoce con diferentes nombres: Daily Scrum (en la Guía Scrum), sincronización matutina, morning circle, daily. El objetivo es sincronizar al equipo, identificar bloqueadores y ajustar los planes del día. El daily no es un informe para el gerente, sino una herramienta de autoorganización del equipo. El equipo decide cómo estructurar la reunión, no el gerente.

El origen del término «standup» proviene de la práctica de reunirse literalmente de pie: los participantes se reúnen frente al tablero y no se sientan. Esto crea una sensación de temporalidad — nadie quiere estar de pie más de 15 minutos. El standup presencial todavía lo utiliza el 60% de los equipos (según Scrum.org 2025), mientras que el resto ha pasado al formato remoto mediante Zoom, Slack Huddle o Teams. En el formato remoto es importante mantener la disciplina: cámaras encendidas, sin multitarea, preparación anticipada de las respuestas.

La Guía Scrum 2025 define el Daily Scrum como un evento para los Developers (desarrolladores). El Product Owner y el Scrum Master pueden asistir pero no es obligatorio. Si el PO o SM asisten, no dirigen la reunión. El equipo elige su propia estructura: las tres preguntas clásicas o un board walk. Punto clave: el daily trata de inspeccionar el progreso hacia el Sprint Goal, no el estado de cada tarea. Si la reunión se convierte en un listado de tareas del tablero, el equipo ha perdido el enfoque en el Sprint Goal.

Tres preguntas del Daily Standup

Pregunta 1: «¿Qué hice ayer para alcanzar el Sprint Goal?» — un breve resumen de las tareas completadas. No «trabajé en APP-123», sino «terminé la pantalla de inicio de sesión, PR enviado a revisión». La redacción «para alcanzar el Sprint Goal» es intencionada: conecta el trabajo diario con el objetivo general del sprint. Si un desarrollador no ve cómo su tarea se relaciona con el Sprint Goal, es una señal de que la tarea quizás no sea necesaria en el sprint actual. En el desarrollo móvil, los resultados de ayer incluyen no solo código sino también tests, documentación y configuración de CI/CD.

Pregunta 2: «¿Qué planeo hacer hoy para alcanzar el Sprint Goal?» — el plan para el día actual. No más de 2-3 elementos. Un desarrollador podría decir: «Hoy terminaré la ViewModel para la pantalla de perfil, escribiré tests unitarios y ejecutaré una compilación en un dispositivo real». Si el plan coincide con lo de «ayer», es señal de que la tarea es demasiado grande y debe descomponerse. La regla de los dos días: si una tarea no se completa en 2 días de trabajo, debe dividirse en subtareas; de lo contrario, se estancará en In Progress durante semanas.

Pregunta 3: «¿Qué bloqueadores están obstaculizando mi progreso?» — la pregunta más importante. Un bloqueador es algo que el desarrollador no puede resolver por sí mismo: esperar una revisión (si se ha superado el SLA de revisión), un emulador que no funciona, una API no terminada, necesidad de acceso al repositorio. Importante: los bloqueadores deben nombrarse pero no resolverse durante el daily. Después de la reunión, el desarrollador y el Scrum Manager / gerente acuerdan resolver el bloqueador. Según Scrum.org (2025), el 70% de los bloqueadores de equipos móviles están relacionados con: espera de revisiones (30%), falta de dispositivos de prueba (20%) y dependencias del backend (20%).

Cómo realizar un standup correctamente

Hora y lugar. El daily se realiza a la misma hora cada día — normalmente al inicio de la jornada laboral (9:00-10:00). Para equipos distribuidos se elige una hora cómoda para todas las zonas horarias. Duración — estrictamente 15 minutos. El temporizador es obligatorio. Si el equipo no termina a tiempo, el problema no es el daily sino el proceso: hay demasiados participantes o se están discutiendo tareas en lugar de solo nombrarlas. La regla del ping-pong: cada participante habla durante no más de 60 segundos. Después de responder, pasa la palabra al siguiente.

Formato Board Walk. Una alternativa a las tres preguntas: el equipo turna para mover tareas en el tablero Scrum mientras comenta los cambios. Un desarrollador toma su tarea de To Do, la mueve a In Progress y dice: «Tomo APP-123 — la pantalla de pedidos, añado el campo de código promocional». Board Walk proporciona una comprensión visual del progreso y revela tareas «olvidadas» — aquellas que llevan 3+ días sin movimiento. Board Walk es preferible para equipos distribuidos con Jira/Linear — todos ven el tablero en lugar de escuchar un monólogo.

Para equipos remotos: las cámaras deben estar encendidas — según Microsoft Research (2025), tener la cámara encendida aumenta la participación en un 40%. Usen una pantalla compartida con el tablero de tareas (Jira, Linear, Miro). Escriban los bloqueadores en el chat — esto crea un registro escrito. Fomenten los emojis de reacción (excepto por instrucción del usuario — los emojis no se usan) — un pulgar arriba en el mensaje de un colega. Después del daily, tomen 2-3 minutos para el parking lot: los temas que requieren discusión separada se anotan en una lista de reuniones de seguimiento. Habilidad clave del Scrum Master: detener la discusión durante el daily y moverla al parking lot.

Errores típicos en las reuniones

Error 1: informe de estado para el gerente. Los desarrolladores se turnan para leer lo que está escrito en Jira, el gerente hace preguntas aclaratorias y la reunión dura 45 minutos. Solución: recordar que el daily es para el equipo, no para el gerente. El gerente puede consultar el estado en el tablero. Si el gerente hace preguntas, muévalas a reuniones 1:1. Un equipo que convierte el daily en un informe de estado pierde 2-3 horas por semana entre todos los participantes. Con 8 desarrolladores, son 16-24 horas-persona al mes — la pérdida de un sprint completo al año.

Error 2: resolver problemas en el momento. Un desarrollador dice «Tengo un error con gRPC — el proyecto no compila» y todo el equipo pasa 20 minutos discutiendo soluciones. Solución: anotar el bloqueador en el parking lot y continuar el daily. Después de la reunión, reunir a las personas relevantes (el desarrollador + quien pueda ayudar) para una discusión de 10 minutos. Según Basecamp (Shape Up), solo el 20% de los problemas descubiertos en los daily requieren discusión de todo el equipo. El resto los resuelve un par de desarrolladores en 10 minutos.

Error 3: retrasos y ausencias. Alguien llega 5 minutos después del inicio y hay que repetir todo. Solución: establecer la regla de que «el daily comienza puntual, los rezagados no entran» o «el que llega tarde paga una multa» (café para el equipo). Más estricto aún: el daily se realiza a una hora fija; si alguien llega tarde sistemáticamente, es un problema de disciplina que se trata en 1:1. El daily es la sincronización del día. Si un desarrollador lo pierde, no está sincronizado y corre el riesgo de hacer el trabajo equivocado para el equipo.

Error 4: demasiados participantes. Un equipo de 15+ personas, cada una hablando un minuto — 20+ minutos en total. Solución: dividir el equipo en subgrupos por funcionalidad/módulo. Cada subgrupo realiza su propio daily (5-7 personas). Un representante de cada subgrupo puede asistir a un standup interequipos (si se necesita sincronización entre equipos). Alternativa: un standup asíncrono mediante Slack/GeekBot donde cada uno escribe qué hizo / planea / bloqueadores.

Standup asíncrono: alternativas

Standup asíncrono — un formato donde los participantes escriben sus respuestas en un chat (Slack, Telegram, Teams) o mediante un bot especializado (GeekBot, Standuply, Status Hero) en lugar de una reunión oral. Adecuado para equipos distribuidos con una diferencia horaria de 3+ horas. Cada participante responde las mismas tres preguntas antes de una hora determinada (por ejemplo, antes de las 11:00). El bot recoge las respuestas y publica un resumen en el canal común. Ventajas: flexibilidad, registro escrito, sin problemas de retrasos.

Desventajas del formato asíncrono: no hay interacción en vivo — se pierden las señales no verbales, es más difícil identificar bloqueadores (un desarrollador puede no escribir sobre un problema). Un bloqueador escrito en un chat puede pasar desapercibido hasta el final del día. Según GitLab (2025), el 40% de los equipos que cambiaron al standup asíncrono volvieron al oral en 3 meses. Recomendación: usen un híbrido — 3 días de standup oral (lun, mié, vie) y 2 días asíncrono (mar, jue). O: standup oral 1-2 veces por semana, asíncrono los días restantes.

Herramientas para standup asíncrono: GeekBot (Slack) — hace las tres preguntas y publica un resumen; Standuply — se integra con Jira y proporciona seguimiento automático; Status Hero — recopila estados y genera informes semanales para la gerencia. La elección de la herramienta depende de la cultura del equipo: en startups, un bot de Slack es suficiente; en entornos empresariales, puede necesitarse Standuply con integración en procesos corporativos. Regla importante: independientemente del formato, las respuestas deben ser visibles para todo el equipo, no solo para el gerente. La transparencia es un valor central de Agile.

Particularidades del daily para equipos móviles

Un equipo móvil se enfrenta a bloqueadores específicos durante el daily. Principales: compilación del proyecto en CI (la compilación de Gradle puede llevar 20+ minutos — si se rompe, el desarrollador pierde una hora depurando), espera de TestFlight / Firebase App Distribution (publicar una compilación a los testers lleva 30-60 minutos), problemas con emuladores y simuladores (Android Emulator requiere KVM/HAXM, iOS Simulator solo en Mac). El daily de un equipo móvil debe incluir una verificación rápida del estado de la compilación: «¿La compilación pasa? ¿Todos los tests están en verde?».

Para proyectos multiplataforma (Flutter, React Native), el daily puede incluir una pregunta sobre el estado del código compartido. Si dos desarrolladores editan simultáneamente el mismo archivo Dart y uno fusiona cambios, el segundo enfrentará conflictos. Consejo: usen Board Walk con un tablero segmentado por plataforma (Android / iOS / Shared). Esto ayuda a visualizar quién trabaja dónde y si los cambios se superponen. Para proyectos Flutter, usen un tablero con columnas para Platform Channel, BLoC/Cubit, UI y Tests.

Preparación para el lanzamiento es otro punto específico del desarrollo móvil en el daily. 3-5 días antes del lanzamiento, añadan la pregunta: «¿La compilación está lista para publicar? ¿Están actualizados todos los metadatos (iconos, capturas de pantalla, descripciones)?». Esto evita situaciones en las que los desarrolladores terminan de codificar el día del lanzamiento mientras la compilación y publicación llevan otras 3-4 horas. Tracker de lanzamiento — un tablero separado con una lista de verificación: actualizar versionCode/versionName, verificar ProGuard, firmar AAB, subir a la consola de desarrollador, escribir notas de la versión.