Los eventos de Scrum son las cuatro reuniones estructuradas que organizan el trabajo de un equipo durante cada Sprint.
El lunes que todo cambió en el equipo de Liverpool
Eran las 9:15 de la mañana de un lunes en las oficinas de Liverpool en Perisur. Daniela, líder de producto, entró a la sala de juntas con cara de preocupación. Su equipo llevaba dos semanas desarrollando una funcionalidad nueva para el app de compras, y nadie sabía con exactitud en qué estado estaba el trabajo. No había reunión de seguimiento, no había momento de revisión, no había espacio para hablar de los problemas. Solo código que avanzaba... o eso creían.
Al final del mes, el equipo entregó algo. Pero no era lo que la empresa necesitaba. Habían construido en la dirección equivocada durante 30 días completos.
Lo que le faltaba a ese equipo no era talento. Le faltaba estructura. Y esa estructura tiene un nombre en Scrum: los eventos.
Por qué los eventos no son simples reuniones
Scrum define cuatro eventos formales que ocurren dentro de cada Sprint. Cada uno tiene un propósito específico, una duración máxima y un momento preciso en el tiempo. No son reuniones opcionales ni de cortesía. Son los momentos donde el equipo toma decisiones, detecta problemas y ajusta su rumbo.
Según el Scrum Guide, el 80% de los problemas de comunicación en equipos ágiles ocurren cuando uno o más de estos eventos se omite o se hace de forma incompleta. No es un dato menor. La disciplina en los eventos es lo que separa a un equipo Scrum funcional de uno que solo usa el nombre.
Conoce cada uno a detalle.
Sprint Planning: el mapa antes del viaje
El Sprint Planning ocurre al inicio de cada Sprint. El equipo completo se reúne para responder dos preguntas fundamentales: ¿qué vamos a construir este Sprint? y ¿cómo vamos a hacerlo?
El Product Owner presenta los elementos más importantes del Product Backlog. El equipo revisa cada uno, hace preguntas y estima el esfuerzo necesario. Al final de la sesión, el equipo tiene un Sprint Backlog: una lista clara de tareas comprometidas para los próximos días.
La duración máxima es de ocho horas para un Sprint de un mes. Para Sprints más cortos, como dos semanas, el tiempo se reduce proporcionalmente a cuatro horas.
Imagina que el equipo digital de FEMSA está a punto de iniciar un nuevo Sprint. El Product Owner propone desarrollar una mejora en el sistema de pagos para su plataforma de conveniencia. Durante el Sprint Planning, los desarrolladores descubren que la tarea es más compleja de lo esperado. Deciden dividirla en tres partes más pequeñas y solo comprometerse con dos de ellas. Eso es exactamente lo que debe pasar: el equipo decide cuánto puede hacer de forma realista.
Daily Scrum: quince minutos que valen horas
El Daily Scrum es una reunión diaria de exactamente 15 minutos. Se hace de pie, a la misma hora, todos los días del Sprint. No es una junta de reportes al jefe. Es una sincronización entre personas que trabajan hacia el mismo objetivo.
Cada miembro del equipo responde tres preguntas: ¿qué hice ayer que ayudó al equipo a avanzar?, ¿qué haré hoy?, ¿hay algo que me esté bloqueando?
Ese último punto es crítico. Los impedimentos que se nombran en el Daily Scrum se convierten en responsabilidad del Scrum Master para resolver. Si nadie los nombra, nadie los resuelve.
Un estudio de McKinsey encontró que los equipos que hacen Daily Scrum de forma consistente reducen sus tiempos de resolución de problemas en un 40% comparado con equipos sin sincronización diaria. Quince minutos al día pueden ahorrarte días de trabajo perdido.
Piensa en un equipo de Bimbo trabajando en un sistema de seguimiento de rutas de distribución. Si un desarrollador descubre el martes que la API del proveedor de mapas cambió sus condiciones, lo dice en el Daily Scrum del miércoles. El equipo ajusta ese mismo día. Sin ese espacio, el problema podría pasar desapercibido hasta el viernes.
Sprint Review: mostrar lo que se construyó
Al final del Sprint, el equipo realiza el Sprint Review. En esta sesión, el equipo presenta el trabajo terminado a los stakeholders: directivos, clientes internos, usuarios representativos o cualquier persona interesada en el producto.
La palabra clave es "terminado". Solo se presenta trabajo que cumple con la definición de hecho del equipo. No se muestran prototipos a medias ni funciones incompletas. Lo que se presenta debe estar listo para usarse.
La duración máxima es de cuatro horas para un Sprint de un mes.
Esta reunión no es una presentación de PowerPoint. Es una demostración real del producto funcionando. El Product Owner confirma qué se completó y qué no. Los stakeholders hacen preguntas y pueden sugerir ajustes al Product Backlog según lo que ven.
Supón que el equipo de Mercado Libre terminó un Sprint donde desarrollaron un nuevo filtro de búsqueda por categoría de precio. En el Sprint Review, el equipo abre la app en vivo y muestra cómo funciona el filtro. El director de producto lo prueba en tiempo real, identifica un comportamiento inesperado y lo agrega como nueva historia al backlog. Eso es feedback real, no supuesto.
Sprint Retrospective: mejorar la forma de trabajar
La Retrospectiva es el evento más subestimado de Scrum, y también el más poderoso. Ocurre después del Sprint Review y antes del siguiente Sprint Planning.
El equipo se reúne para hablar, no del producto, sino de sí mismo. ¿Qué funcionó bien? ¿Qué no funcionó? ¿Qué vamos a hacer diferente el próximo Sprint?
La duración máxima es de tres horas para un Sprint de un mes.
El resultado esperado no es una lista de quejas. Es un plan concreto de mejora con al menos un cambio específico que el equipo implementará en el próximo Sprint. Un cambio. Solo uno. Pero real y medible.
Equipos que hacen Retrospectivas consistentes mejoran su velocidad de entrega hasta un 25% en seis meses, según datos de agencias de transformación digital en México que trabajan con empresas como OXXO y Liverpool. El aprendizaje sistemático no es un lujo. Es ventaja competitiva.
Los errores más comunes al usar los eventos
El primer error es convertir el Daily Scrum en una junta de reporte al Scrum Master. Cuando el Scrum Master hace preguntas y el equipo "le informa", se rompe la dinámica de equipo autoorganizado. Las respuestas deben dirigirse al equipo, no al facilitador.
El segundo error es omitir la Retrospectiva cuando hay presión de tiempo. Muchos equipos la cancelan cuando están muy ocupados. Pero eso es exactamente cuando más la necesitan. Un equipo bajo presión que no reflexiona repite los mismos errores Sprint tras Sprint.
El tercer error es hacer el Sprint Planning sin tener el backlog refinado. Si las historias de usuario no están claras antes de la reunión, el Planning se convierte en una sesión de redacción, no de planificación. El tiempo se agota y el equipo entra al Sprint sin claridad.
El cuarto error es invitar a demasiadas personas al Sprint Review. Cuando hay veinte personas en la sala, nadie habla con honestidad. La reunión se vuelve política, no colaboración.
El regreso a Perisur
Daniela implementó los cuatro eventos en su equipo de Liverpool. No fue fácil al inicio. El primer Daily Scrum duró 45 minutos porque todos querían hablar de todo. La primera Retrospectiva generó incomodidad porque nadie estaba acostumbrado a hablar de sus errores en voz alta.
Pero al tercer Sprint, algo cambió. Los problemas se detectaban el mismo día en que aparecían. El Product Owner recibía el trabajo terminado y podía mostrarlo a sus directivos con confianza. Y el equipo, por primera vez, sentía que tenía el control de su propio proceso.
No fue magia. Fueron cuatro reuniones bien hechas, en el momento correcto, con el propósito correcto.
Eso es lo que los eventos de Scrum hacen: le dan al equipo los momentos para pensar, ajustar y mejorar. Sin ellos, el trabajo avanza a ciegas. Con ellos, el equipo ve a dónde va.