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 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.

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.
• Todos los eventos relacionados con el Sprint deben ejecutarse (Reunión de Planificación, Reunión Diaria, Reunión de Revisión y Reunión de 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.

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 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 el equipo de desarrollo debe resolverlo cuanto antes.
• Surge un cambio urgente que debe introducirse de inmediato al incremento de producto.

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, 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.
• 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.

3.2 – Reunión de Planificación del Sprint (Sprint Planning)

• 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 tiempo máximo del evento.

3.2.1 - Datos del evento

• Duración: 2 horas por cada semana de Sprint a planificar. (Duración máxima de 8 horas para un Sprint de 4 semanas).
• Participantes: Todo el Equipo Scrum (Product Owner + Scrum Master + Developers).
• Agenda de la reunió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 Reunión de 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.
   • Identificar las dependencias que puedan existir.
   • Se realiza la estimación de los elementos seleccionados para su desarrollo.
   • El equipo se autoasigna los elementos del Sprint Backlog.

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

   • Identificar (desglosar) las tareas que deben ejecutarse para “terminar” los elementos del Sprint Backlog.
   • Asegurar que todo el Equipo entiende cómo crear un incremento cumpliendo con la Definición de Terminado (Definition Of Done).

3.3 - Daily Scrum (Scrum Diario)

El Scrum Diario es una reunión con un bloque de tiempo de 15 minutos que tiene el propósito de inspeccionar el progreso hacia el Objetivo del Sprint (Sprint Goal). El Scrum Diario se realiza diariamente 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.

3.3.1 - Datos del evento

• Duración: 15 minutos máximo.
• Participantes: Los Developers y el Scrum Master
• Agenda de la reunión: 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:
  • ¿Qué hice hoy?
  • ¿Qué haré mañana?
  • ¿Existe algún impedimento que esté afectando o nos pueda afectar?
• Consideraciones:
  • Durante el Scrum Diario el Equipo coordina y 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.
  • Es muy común que el Equipo se vuelva a reunir 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.
  • El Equipo usa el Scrum Diario para evaluar el progreso hacia el Objetivo del Sprint.
  • El Scrum Master se asegura de que el Equipo lleve a cabo la reunión, 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 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).

3.4 – Reunión de Revisión del Sprint (Sprint Review)

Al final del Sprint se lleva a cabo la Reunión de Revisión de Sprint para inspeccionar 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.

3.4.1 Datos del evento

• 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: Todo el Equipo Scrum + Los Interesados clave que sean invitados por el Product Owner

• Agenda de la reunió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.

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. 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 (Sprint Retrospective)

El tema principal de la Reunión de Retrospectiva del Sprint es la identificación de posibles mejoras que puede incorporar el Equipo Scrum 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 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.