2.3 - Eventos en Scrum

Los eventos en Scrum, también conocidos como sesiones de trabajo, son momentos estructurados que facilitan la colaboración, la transparencia y la inspección regular, promoviendo una ejecución ágil de los proyectos. Aquí está una descripción concisa de cada uno y su propósito:

Sprint: Es el corazón de Scrum, un periodo de tiempo determinado (usualmente de dos a cuatro semanas) donde se realiza un incremento de producto "potencialmente entregable". Sirve para mantener al equipo enfocado en un conjunto de objetivos específicos.
Planificación del Sprint (Sprint Planning): Al inicio de cada sprint, el equipo se reúne para planificar y acordar los elementos del backlog del producto que serán abordados durante ese sprint. Facilita la colaboración y la alineación de expectativas entre los miembros del equipo.
Daily Scrum (Scrum Diario): Es una reunión corta (15 minutos) que tiene lugar cada día durante el sprint. Permite a los desarrolladores compartir actualizaciones sobre su progreso y planificar el trabajo del día, ayudando a identificar obstáculos tempranamente.
Revisión del Sprint (Sprint Review): Al final del sprint, el equipo se reúne para evaluar y demostrar el trabajo realizado. Facilita la inspección del incremento de producto y ajustes basados en el feedback de los stakeholders.
Retrospectiva del Sprint (Sprint Retrospective): Es una reunión que ocurre después de la revisión del sprint y antes de la próxima planificación del sprint. Sirve para que el equipo reflexione sobre su forma de trabajar y acuerde maneras de mejorar para el próximo sprint.

En Scrum existen diferentes eventos predefinidos con el fin de crear regularidad, minimizar la necesidad de reuniones innecesarias y permitir la transparencia.

Todos los eventos tienen un periodo de tiempo limitado (time-box), de tal modo que todos tienen una duración máxima, y se llevan a cabo al mismo tiempo y en el mismo lugar para reducir la complejidad.

1. El Sprint

¿De qué se trata?

Los Sprints son el latido del corazón de Scrum, donde todas las ideas se convierten en valor. El Sprint es un evento con un tiempo asignado (time-box) de 1 a 4 semanas durante el cual se crea un incremento de producto “Terminado” utilizable y potencialmente desplegable.

Cada nuevo Sprint comienza inmediatamente después de la finalización del Sprint anterior. Los Sprints contienen y consisten en la Planificación del Sprint, los Scrum Diarios, el desarrollo del trabajo, la Revisión del Sprint, y la Retrospectiva del Sprint.

Cada Sprint puede considerarse como un “mini-proyecto” con un horizonte no mayor de un mes. Al igual que los proyectos, los Sprints se usan para alcanzar una meta. Cada Sprint tiene un objetivo de lo que se construirá, es decir, el Objetivo del Sprint (Sprint Goal), un diseño y un plan flexible que guiará su construcción, el trabajo del equipo y el incremento de producto resultante.

Los Sprints habilitan la predictibilidad al asegurar la inspección y adaptación del progreso al menos en cada mes calendario.

¿Cuál es su duración?

Típicamente, el Sprint dura entre 1 y 4 semanas (un mes calendario), siendo 2 semanas el duración más común.

Cuando el horizonte de un Sprint es mayor a un mes, la complejidad podría incrementarse y el riesgo podría aumentar.

¿Quiénes participan y cómo se involucran?

Scrum Master: Ayuda al equipo a mantenerse enfocado en la meta del Sprint, facilita la resolución de impedimentos y garantiza que se sigan las prácticas Scrum.
Product Owner: Asegura que el equipo tenga una visión clara del valor que deben entregar, prioriza las tareas y proporciona claridad sobre las historias de usuario o requerimientos.
Developers: Implementan las funcionalidades, mantienen una comunicación constante sobre el progreso y colaboran para cumplir con la meta del Sprint.

¿Qué se necesita para el evento?

Un Product Backlog priorizado.
Un Sprint Goal o meta definido en la Planificación del Sprint.
Un Sprint Backlog con los elementos seleccionados y su plan de trabajo.

¿Qué sucede durante el Sprint?

No hay una "agenda" para el Sprint como tal, pero el flujo general es:

Comenzar a trabajar en los elementos del Sprint Backlog.
Realizar reuniones diarias de sincronización (Daily Scrum).
Trabajar colaborativamente para resolver impedimentos.
Asegurarse de que se cumplan las definiciones de terminado ("Definition of Done") para los ítems completados.

¿Qué resulta del Sprint?

Un incremento potencialmente entregable del producto.
Actualizaciones al Product Backlog basadas en el aprendizaje y el trabajo durante el Sprint.

Consideraciones sobre la duración del Sprint

Una vez que comienza un Sprint, su duración es fija y no puede acortarse o alargarse.
Durante el Sprint no se realizan cambios que puedan afectar al objetivo del Sprint.
La calidad del producto no debe disminuir.
El alcance puede clarificarse y renegociarse con el Product Owner a medida que se va aprendiendo más.
Todos los eventos relacionados con el Sprint deben ejecutarse dentro del tiempo del Sprint (Planificación, Scrum Diario, Revisión y Retrospectiva), la falta de alguno de estos eventos da como resultado una reducción de la transparencia y constituye una oportunidad perdida de inspección y adaptación.
La duración de los Sprint dependerá de los siguientes factores:
- Fechas de entrega acordadas con el cliente
- Experiencia del equipo (a menor experiencia con Scrum, los Sprints deberían ser más cortos)
- Restricciones propias para la construcción del producto
La duración del Sprint es definida por todo el Equipo Scrum con las recomendaciones del Scrum Master, quienes a su vez deberán llegar a un consenso con el Product Owner.

¿Se puede cancelar un Sprint? Un Sprint puede cancelarse antes que el periodo de tiempo llegue a su fin. Algunas de las razones por las que se podría cancelar un Sprint son:

La organización cambia el Objetivo del Producto (Product Goal) y eso afecta el entregable del Sprint que se está ejecutando.

Las condiciones del mercado o de la tecnología cambian.

El objetivo del Sprint quedó obsoleto.

Surge un error sobre un producto que está en ambiente de producción y los Developers deben resolverlo cuanto antes.

Surge un cambio urgente que debe introducirse de inmediato al incremento de producto.

Consideraciones sobre la cancelación del Sprint

Solo el Product Owner tiene la autoridad para cancelar el Sprint, aunque puede hacerlo bajo la influencia de los interesados, de los Developers o del Scrum Master.

Debido a la corta duración de los Sprints, su cancelación rara vez tiene sentido.

Cuando se cancela un Sprint se revisan los elementos que se hayan completado y “Terminado”. Si una parte del trabajo es potencialmente entregable, el Product Owner normalmente la acepta.

Si el Sprint ha sido cancelado, todos los elementos del Sprint Backlog que no hayan sido completados se vuelven a estimar para el siguiente Sprint o se vuelven a introducir en el Product Backlog para desarrollarse en futuros Sprints.

Aunque se cancele un Sprint de igual manera consume recursos ya que el equipo debe reagruparse de nuevo para otra Planificación de Sprint para empezar otro Sprint.

Las cancelaciones del Sprint son a menudo traumáticas para el Equipo Scrum y son muy poco comunes.

2. Planificación del Sprint (Sprint Planning)

¿De qué se trata?

La Planificación del Sprint es una sesión de trabajo en la que el equipo Scrum determina qué elementos del Product Backlog se trabajarán durante el próximo Sprint y cómo se abordarán, es decir un plan de trabajo, y este plan se crea mediante el trabajo colaborativo de todo el equipo Scrum.

En esta sesión se establece el alcance y el objetivo para las próximas semanas (Sprint Goal).

El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su propósito.
El Scrum Master enseña al Equipo Scrum a mantenerse dentro del tiempo máximo del evento.
El Product Owner es el encargado de dirigir la sesión de planificación, ya que él tiene la información que se usará como insumo para seleccionar el trabajo.

¿Cuál es su duración?

Máximo 8 horas para un Sprint de un mes. Para Sprints más cortos, la duración se reduce proporcionalmente (por ejemplo, 4 horas para un Sprint de dos semanas).

¿Quién participa y cómo se involucra?

Scrum Master: Facilita la sesión y asegura que todos entiendan el propósito y la agenda de la sesión. Resuelve impedimentos que puedan surgir durante la planificación.
Product Owner: Explica claramente los ítems del Product Backlog y ayuda al equipo a priorizar el trabajo basándose en el valor y las necesidades del negocio. Propone el objetivo del Sprint.
Developers: Determinan el trabajo que pueden realizar durante el Sprint y descomponen los ítems en tareas con sus respectivas estimaciones.

¿Qué se necesita para el evento?

El Product Backlog actualizado.
El último incremento del producto.
Rendimiento pasado del equipo (por ejemplo, velocidad).
"Borrador" de los elementos opcionados para trabajar en este Sprint (identificados previamente por el Product Owner).

Agenda de la sesión

1. ¿Por qué este Sprint es valioso?

El Product Owner propone cómo el producto podría aumentar su valor y utilidad en el Sprint.
Todo el equipo de Scrum colabora para definir el Objetivo de Sprint (Sprint Goal) durante la Planificación.

2. ¿Qué puede hacerse en este Sprint?

Se identifican los cambios y/o riesgos que puedan afectar este Sprint.
En equipo se seleccionan los elementos del Product Backlog que harán parte de este Sprint, es decir, definen el Sprint Backlog.
Se identifican las dependencias que puedan existir.
Los elementos seleccionados se descomponen en tareas detalladas y se realiza su estimación.
Los Developers (y algunos casos también el Scrum Master si ejecuta trabajo del Sprint) se autoasignan los elementos del Sprint Backlog.

3. ¿Cómo se conseguirá completar el trabajo seleccionado?

Se explica el detalle de las tareas y esfuerzos necesarios que deben ejecutarse para "terminar" los elementos del Sprint Backlog.
Se asegura que todo el Equipo entiende cómo crear un incremento cumpliendo con la Definición de Terminado (Definition Of Done).

¿Qué resulta del evento?

El objetivo del Sprint (Sprint Goal) definido.
Lista de ítems del Product Backlog seleccionados para el Sprint (Sprint Backlog).
El plan sobre cómo el equipo abordará las tareas (como parte del Sprint Backlog).

Consideraciones adicionales

La reunión debe ser colaborativa; todas las decisiones se toman en conjunto.
Es vital no sobrecargar al equipo durante el Sprint. Es preferible subestimar que sobreestimar.
La claridad en el objetivo del Sprint ayuda a mantener al equipo alineado y enfocado.
El equipo debe estar preparado para adaptarse a los cambios, manteniendo la visión y el objetivo del Sprint.

3. Daily Scrum (Scrum Diario)

¿De qué se trata?

El Scrum Diario es una corta sesión diaria (15 minutos) que tiene como objetivo inspeccionar el progreso de los Developers hacia el Objetivo del Sprint (Sprint Goal) e identificando posibles impedimentos para la ejecución.

El Scrum Diario se realiza para cada día del sprint.

Nota: Si el Product Owner o el Scrum Master están desarrollando elementos del Sprint Backlog, entonces pueden participar como Developers.

¿Cuál es su duración?

Máximo 15 minutos.

¿Quiénes participan y cómo se involucran?

Scrum Master: Asegura que la reunión ocurra diariamente, facilita la solución de impedimentos externos y mantiene la estructura y duración de la reunión.
Product Owner: Puede asistir para escuchar, pero no interfiere en la dinámica de la reunión. Si tiene comentarios o inquietudes, los discute fuera del Daily Scrum.
Developers: Activamente participan compartiendo su progreso, plan para el día y señalando impedimentos.

Nota: El Scrum Master y Product Owner pueden asistir, pero la reunión es principalmente para los Developers.

¿Qué se necesita para el evento?

Sprint Backlog.
Progreso del día anterior (tareas completadas, en progreso, en pruebas, pendientes).
Posibles impedimentos identificados.

Posible agenda de los daily

Nota: El Scrum Master y los Developers tienen la libertad de seleccionar la estructura y técnicas que deseen para la ejecución de esta reunión; sin embargo, el Scrum Master tiene la opción de hacer las siguientes preguntas a los Developers:

¿Qué hice hoy?
¿Qué haré mañana?
¿Existe algún impedimento que esté afectando o nos pueda afectar?

¿Qué resulta de los daily?

Entendimiento compartido del progreso hacia el Objetivo del Sprint.
Identificación y registro de impedimentos.
Ajustes en el plan diario de trabajo, si es necesario.

Consideraciones adicionales sobre los daily

El Scrum diario se realiza a la misma hora y lugar todos los días para reducir la complejidad. Por lo general se realiza antes de finalizar la jornada de trabajo del Equipo.
Durante el Scrum Diario el Equipo coordina y planea el trabajo para las siguientes 24 horas.
Si surgen temas que requieran discusiones más amplias, se deben tratar fuera del Scrum diario para no desviar el propósito principal.
El Scrum Master se asegura de que la reunión se ejecute diariamente, pero son los Developers los responsables de dirigir el Scrum Diario, es decir que, no es obligatoria la presencia del Scrum Master para que se lleve a cabo el Scrum Diario.
El Scrum Master enseña al Equipo a mantener el Scrum Diario dentro de un bloque de tiempo de máximo 15 minutos.
El Scrum Diario es una reunión interna del Equipo. Si otras personas están presentes, el Scrum Master se asegura de que no interrumpan la reunión ni alteren la planificación del trabajo.
Los Scrum Diarios mejoran la comunicación, identifican los impedimentos relacionados con desarrollo del trabajo, resaltan y promueven la toma rápida de decisiones y mejoran el nivel de conocimiento del Equipo.
Durante los Scrum Diarios se actualizan el Burndown chart y el Scrum Board.
Esta reunión por lo general se realiza de pie con el fin de garantizar el cumplimiento del tiempo asignado, por lo que también se le puede conocer como el Scrum Diario de Pie (Daily Standup Meeting).

4. Revisión del Sprint (Sprint Review)

¿De qué se trata la Revisión del Sprint?

Al final del Sprint se lleva a cabo la Revisión de Sprint en la que se inspecciona el Incremento que se produjo durante el Sprint y adaptar el Product Backlog si fuese necesario.

El Equipo Scrum realiza una demostración del incremento y se revisa el progreso con respecto al Objetivo de Producto; basándose en esto y en cualquier cambio que deba considerarse, los asistentes colaboran para determinar los elementos que podrían desarrollarse en el siguiente Sprint para optimizar el valor.

Se trata de una sesión de trabajo, no de una reunión de seguimiento, y la presentación del Incremento tiene como objetivo facilitar la retroalimentación para el equipo Scrum y fomentar la colaboración.

El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su propósito. El Scrum Master enseña a todos a mantener el evento dentro del bloque de tiempo fijado.

¿Cuál es la duración de la Revisión del Sprint?

Normalmente, dura máximo 4 horas para un Sprint de 4 semanas (la duración suele ser proporcional al largo del Sprint, por lo que para Sprints de 2 semanas, suele ser de 2 horas).

¿Quiénes participan de la Revisión del Sprint?

Scrum Master: Facilita la sesión y garantiza que se siga la agenda.
Product Owner: Presenta los ítems del Product Backlog completados, resalta el valor del trabajo realizado y lidera la discusión sobre las prioridades.
Developers: Demuestran el trabajo realizado y responden preguntas técnicas.
Stakeholders: Brindan retroalimentación y aclaran dudas o expectativas.

¿Qué se necesita para la Revisión del Sprint?

Incremento de producto terminado del Sprint.
Product Backlog.
Estimaciones del trabajo (en el Sprint Backlog).

Agenda de la Revisión del Sprint

El Equipo habla acerca de qué estuvo bien durante el Sprint, qué problemas aparecieron y cómo fueron resueltos esos problemas.
El Equipo hace una demostración del trabajo que ha "Terminado" y responde preguntas acerca del Incremento y su funcionalidad.
El Product Owner habla acerca del Product Backlog en su estado actual. Proyecta objetivos probables y posibles fechas de entrega basándose en el progreso obtenido hasta la fecha (si fuera necesario).
El Product Owner realiza la aprobación de los elementos del Sprint Backlog que se han "Terminado" y rechaza los que no se han "Terminado" y con esto determinar la Deuda Técnica.
Seguimiento y control del presupuesto, capacidades potenciales y mercado para la próxima entrega prevista del producto.
Revisión del estado de los cambios que fueron planificados para este Sprint y revisión del estado de los riesgos que afectaron este Sprint.
Refinamiento (grooming) del Product Backlog, en el que todo el Equipo colabora acerca de qué hacer a continuación, de modo que esta reunión proporcione información de entrada valiosa para Reuniones de Planificación de Sprints subsiguientes.

¿Qué resulta de la Revisión del Sprint?

El resultado de la Revisión de Sprint es un Sprint Backlog revisado, además de una identificación de alto nivel de los posibles elementos del Product Backlog que se pueden desarrollar para el siguiente Sprint.
Retroalimentación sobre el Incremento de producto.
Actualización del Product Backlog con posibles nuevos ítems o cambios.
Claridad sobre la dirección y prioridades del producto.

Consideraciones adicionales la Revisión del Sprint

Aunque se busca retroalimentación, la Revisión del Sprint no es únicamente una sesión de aprobación; se verifica que el trabajo esté "terminado" según la Definición de Terminado (DoD).
Es esencial tener un ambiente abierto donde las partes interesadas sientan la libertad de dar retroalimentación honesta y constructiva sobre el producto.

5. Retrospectiva del Sprint (Sprint Retrospective)

¿De qué se trata una retrospectiva?

La Retrospectiva del Sprint es una sesión donde el equipo Scrum reflexiona sobre el Sprint que acaba de terminar para identificar oportunidades de mejora y planificar acciones concretas para próximos Sprints.

¿Cuál es la duración de una retrospectiva?

Suele durar alrededor de 3 horas para un Sprint de 4 semanas (puede ser proporcionalmente menos para Sprints más cortos, por ejemplo, alrededor de 45 minutos a 1.5 horas para Sprints de 2 semanas).

¿Quiénes participan y cómo se involucran?

Scrum Master: Facilita la discusión, asegura un ambiente seguro para que todos expresen sus opiniones y ayuda al equipo a identificar áreas de mejora.
Product Owner: Aporta desde su perspectiva sobre el desarrollo del producto, prioridades y feedback del cliente.
Developers: Comparten feedback, discuten desafíos y proponen soluciones.

¿Qué se necesita para el evento?

Feedback y observaciones del equipo sobre el Sprint que terminó.
Datos y métricas relevantes del Sprint (como el Burndown Chart).
Acciones de mejora de Retrospectivas anteriores.

Agenda de una retrospectiva

Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas.
Reflexionar sobre lo que salió bien y lo que no durante el Sprint.
Discutir las causas de los desafíos y problemas.
Identificar oportunidades de mejora y priorizarlas.
Crear un plan o establecer acciones concretas para implementar las mejoras a la forma en la que el Equipo Scrum desempeña su trabajo.

¿Qué resulta de una retrospectiva?

Acciones concretas para implementar mejoras en el próximo Sprint.
Comprensión compartida de cómo mejorar el proceso de trabajo.

Consideraciones adicionales de una retrospectiva

La Retrospectiva es un espacio seguro donde todos los miembros del equipo deben sentirse cómodos compartiendo su feedback sin temor a represalias.
Las acciones de mejora deben ser específicas, medibles y asignadas para garantizar su implementación.
Es esencial revisar las acciones de mejora de retrospectivas anteriores para evaluar su impacto y asegurar la mejora continua.