Eventos en Scrum

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

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.

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.

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 están limitados a mínimo 1 semana y máximo un mes calendario (4 semanas). Cuando el horizonte de un Sprint es mayor a un mes, la definición de lo que se está construyendo podría cambiar, la complejidad podría incrementarse y el riesgo podría aumentar.

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

Consideraciones sobre la duración del Sprint

Una vez que comienza un Sprint, su duración es fija y no puede acortarse o alargarse.
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.
Los Sprints pueden tener duración variable (conservando la regla de 1 a 4 semanas). La duración de los Sprint dependerá de los siguientes factores:
- Fechas de entrega acordadas
- 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, por lo general la definición aproximada de la duración de los Sprints se hace durante la Definición del Cronograma de Entregas.

Cancelación del 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?

Todo el equipo Scrum:

Scrum Master
Product Owner
Developers

¿Qué se necesita para el evento? (Entradas)

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é hace cada rol?

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é resulta del evento? (Salidas)

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 reunió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én participa?

Developers.
Scrum Master.

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

¿Qué se necesita para el evento? (Entradas)

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

Agenda de la sesión

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é hace cada rol?

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.

¿Qué resulta del evento? (Salidas)

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

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?

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 su duración?

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

¿Quién participa?

Scrum Master.
Product Owner.
Developers.
Stakeholders o partes interesadas (pueden ser clientes, usuarios, entre otros).

¿Qué se necesita para el evento? (Entradas)

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

Agenda de la sesión

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é hace cada rol?

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é resulta del evento? (Salidas)

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

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?

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 su duración?

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

¿Quién participa?

Scrum Master.
Product Owner.
Developers.

¿Qué se necesita para el evento? (Entradas)

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 la sesión

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.
Establecer acciones concretas para el siguiente Sprint.

¿Qué hace cada rol?

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. Salidas (¿Qué resulta del evento?):

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

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.

Duración: 1 hora por cada semana de Sprint a revisar. (Duración máxima de 4 horas para un Sprint de 4 semanas).
Participantes: Los Developers y el Scrum Master (no se recomienda que el Product Owner haga parte de esta reunión).
Agenda de la reunión:
- Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas.
- Inspeccionar sobre si el equipo entendió y cumplió con la Definición de Terminado (Definition Of Done).
- Identificar y ordenar los elementos más importantes que salieron bien y las posibles mejoras que puede incorporar el Equipo Scrum en próximos Sprints.
- Crear un plan para implementar las mejoras a la forma en la que el Equipo Scrum desempeña su trabajo.