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.

3.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 un proyecto con un horizonte no mayor de un mes. Al igual que los proyectos, los Sprints se usan para alcanzar algo. Cada Sprint tiene un objetivo de lo que se construirá, 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 un mes calendario. Cuando el horizonte de un Sprint es demasiado grande, 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. dibujo

3.1.1 - Consideraciones sobre la duración del Sprint

Una vez que comienza un Sprint, su duración es fija y no puede acortarse o alargarse.
Los otros eventos pueden terminar siempre que se alcance el objetivo del evento, asegurando que se emplee una cantidad apropiada de tiempo sin permitir desperdicio en el proceso.
Todos los eventos relacionados con el Sprint deben ejecutarse, 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.
Dentro de un mismo proyecto, 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 del proyecto
La duración del Sprint es definida por el Equipo de Desarrollo con las recomendaciones del Scrum Master, quienes a su vez deberán llegar a un consenso con el Product Owner, por lo general esto se hace durante la Definición del Cronograma de Entregas (7.1.5).

3.1.2 - 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 la dirección del proyecto y eso afecta el entregable del Sprint.
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 el equipo de desarrollo debe resolverlo cuanto antes.
Surge un cambio urgente que debe introducirse de inmediato.

Algunas consideraciones que se deben tener en cuenta sobre la cancelación de los Sprint son:

Solo el Product Owner tiene la autoridad para cancelar el Sprint, aunque puede hacerlo bajo la influencia de los interesados (7.1.1.2), del Equipo de Desarrollo 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 todos los Elementos del Product Backlog que se hayan completado y “Terminado”. Si una parte del trabajo es potencialmente entregable, el Product Owner normalmente la acepta.
Todos los elementos del Product Backlog no completados se vuelven a estimar y se vuelven a introducir en el Product Backlog. El trabajo finalizado en ellos pierde valor con rapidez y por lo general debe volverse a estimar.
Las cancelaciones de Sprint consumen recursos ya que todos se reagrupan en 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.

dibujo

3.2 – Reunión de Planificación del Sprint

En este evento se planifica el trabajo a realizar durante un Sprint.
Este plan se crea mediante el trabajo colaborativo de todo el Equipo Scrum.
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 periodo de tiempo.

3.2.1 - Datos del evento

Duración: 2 horas por cada semana de Sprint a planificar. (Duración máxima de ocho horas).
Participantes: Todo el Equipo Scrum (Sección ¡Error! No se encuentra el origen de la referencia.).
¿Qué se hace en la reunión?

¿Qué puede terminarse en este Sprint?

Se identifican los cambios que deben introducirse en este Sprint (Sección 6.5).
Seleccionar los elementos del Product Backlog.
Identificar las tareas que deben ejecutarse para “terminar” esos elementos.
Identificar las dependencias que puedan existir.
Se realiza la estimación de los elementos seleccionados para su desarrollo.
El equipo de desarrollo se autoasigna los elementos del Product Backlog.

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

¿Qué riesgos podrán afectarnos este Sprint? (Sección 0)

Formalizar el objetivo del Sprint

El objetivo del Sprint se plasma en el Sprint Backlog (Sección 4.2 - Sprint Backlog)

3.3 - Daily Scrum (Scrum Diario)

El Scrum Diario es una reunión con un bloque de tiempo de 15 minutos para el Equipo de Desarrollo. El Scrum Diario se realiza diariamente para cada día del sprint.

3.3.1 - Datos del evento

Duración: 15 minutos máximo.
Participantes: El Equipo de Desarrollo y el Scrum Master
¿Qué se hace en la reunión?
El Equipo de Desarrollo responde las siguientes preguntas:
- ¿Qué hice hoy?
- ¿Qué haré mañana?
- ¿Existe algún impedimento que está afectando o nos pueda afectar?
Durante el Scrum Diario el Equipo de Desarrollo planea el trabajo para las siguientes 24 horas.
El Scrum Diario optimiza la colaboración y el desempeño del equipo inspeccionando el trabajo avanzado desde el último Scrum Diario y proyectando el trabajo a realizar a continuación.
El Equipo de Desarrollo o los miembros del equipo a menudo se vuelven a reunir inmediatamente después del Scrum Diario, para tener discusiones detalladas, o para adaptar o replanificar el resto del trabajo del Sprint.
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 de Desarrollo.
El Equipo de Desarrollo usa el Scrum Diario para evaluar el progreso hacia el Objetivo del Sprint.
El Scrum Diario optimiza las posibilidades de que el Equipo de Desarrollo cumpla el Objetivo del Sprint.
El Scrum Master se asegura de que el Equipo de Desarrollo tenga la reunión, pero es el Equipo de Desarrollo el responsable 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 de Desarrollo a mantener el Scrum Diario en los límites del bloque de tiempo de 15 minutos.
El Scrum Diario es una reunión interna del Equipo de Desarrollo. Si otras personas están presentes, el Scrum Master se asegura de que no interrumpan la reunión.
Los Scrum Diarios mejoran la comunicación, eliminan la necesidad de realizar otras reuniones, identifican impedimentos a remover relativos al desarrollo, resaltan y promueven la toma rápida de decisiones y mejoran el nivel de conocimiento del Equipo de Desarrollo.
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).

3.4 – Reunión de Revisión del Sprint

Al final del Sprint se lleva a cabo una Revisión de Sprint para inspeccionar el Incremento y adaptar el Product Backlog si fuese necesario. Durante la Revisión de Sprint, el Equipo Scrum y los interesados colaboran acerca de lo que se hizo durante el Sprint. Basándose en esto y en cualquier cambio al Product Backlog durante el Sprint, los asistentes colaboran para determinar las siguientes cosas que podrían hacerse para optimizar el valor. Se trata de una reunión informal, no una reunión de seguimiento, y la presentación del Incremento tiene como objetivo facilitar la retroalimentación de información 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.

3.4.1 Datos del evento

Duración: 1 hora por cada semana de Sprint a revisar. (Duración máxima de cuatro horas).
Participantes: Todo el Equipo Scrum + Los Interesados clave que sean invitados por el Product Owner
¿Qué se hace en la reunión?
- El Equipo de Desarrollo habla acerca de qué estuvo bien durante el Sprint, qué problemas aparecieron y cómo fueron resueltos esos problemas.
- El Equipo de Desarrollo 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 fechas de entrega en el tiempo basándose en el progreso obtenido hasta la fecha (si fuera necesario).
- El Product Owner realiza la aprobación de los elementos del Product Backlog que se han “Terminado” y rechaza los que no se han “Terminado” y con esto determinar la Deuda Técnica.
- El equipo completo colabora acerca de qué hacer a continuación, de modo que la Revisión del Sprint proporcione información de entrada valiosa para Reuniones de Planificación de Sprints subsiguientes.
- Revisión de la cronología, presupuesto, capacidades potenciales y mercado para la próxima entrega prevista del producto.

El resultado de la Revisión de Sprint es un Product Backlog revisado que define los elementos del Product Backlog posibles para el siguiente Sprint. Es posible además que el Product Backlog reciba un ajuste general para enfocarse en nuevas oportunidades.

3.5 – Reunión de Retrospectiva del Sprint

El tema principal de la Reunión de Retrospectiva del Sprint es la identificación de posibles mejoras que puede incorporar el Equipo en Próximos Sprints.

3.5.1 - Datos del evento

Duración: 1 hora por cada semana de Sprint a revisar. (Duración máxima de cuatro horas).
Participantes: Equipo de Desarrollo y el Scrum Master (no se recomienda que el Product Owner haga parte de esta reunión).
¿Qué se hace en la reunión?
- Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas.
- Identificar y ordenar los elementos más importantes que salieron bien y las posibles mejoras que puede incorporar el Equipo en Próximos Sprints.
- Crear un plan para implementar las mejoras a la forma en la que el Equipo Scrum desempeña su trabajo.