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 proyecto“mini-proyecto” con un horizonte no mayor de un mes. Al igual que los proyectos, los Sprints se usan para alcanzar algo.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.calendario (4 semanas). Cuando el horizonte de un Sprint es demasiadomayor grande,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.

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,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.
• Dentro de un mismo proyecto, losLos 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 proyectoproducto
• La duración del Sprint es definida por todo el Equipo de DesarrolloScrum con las recomendaciones del Scrum Master, quienes a su vez deberán llegar a un consenso con el Product Owner, por lo general estola definición aproximada de la duración de los Sprints se hace durante la Definición del Cronograma de Entregas (7.1.5).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 lael direcciónObjetivo del proyectoProducto (Product Goal) y eso afecta el entregable del Sprint.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.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 (7.1.1.2), del Equipointeresados, de Desarrollolos 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 todos los Elementos del Product Backlogelementos que se hayan completado y “Terminado”. Si una parte del trabajo es potencialmente entregable, el Product Owner normalmente la acepta.
• TodosSi el Sprint ha sido cancelado, todos los elementos del ProductSprint Backlog que no hayan sido completados se vuelven a estimar ypara el siguiente Sprint o se vuelven a introducir en el Product Backlog.Backlog Elpara trabajo finalizadodesarrollarse en ellosfuturos pierde valor con rapidez y por lo general debe volverse a estimar.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.

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 periodotiempo demáximo tiempo.del evento.

3.2.1 - Datos del evento

• Duración: 2 horas por cada semana de Sprint a planificar. (Duración máxima de ocho8 horas)horas para un Sprint de 4 semanas).
• Participantes: Todo el Equipo Scrum (SecciónProduct ¡Error!Owner No+ seScrum encuentraMaster el+ origenDevelopers).
• Agenda de la referencia.).
reunión:
• ¿Qué se hace en 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 terminarsehacerse en este Sprint?

• Se identifican los cambios y/o riesgos que debenpuedan introducirse enafectar este Sprint (Sección 6.5).Sprint.
• SeleccionarEn equipo se seleccionan los elementos del Product Backlog.
• Identificar las tareasBacklog que debenharán ejecutarseparte parade “terminar”este esosSprint, elementos.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 de desarrollo se autoasigna los elementos del ProductSprint Backlog.

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

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

tareas

que
3. Formalizardeben elejecutarse objetivopara del“terminar” Sprint
los

• El objetivoelementos del Sprint seBacklog.
plasma
• Asegurar enque todo el SprintEquipo Backlogentiende cómo crear un incremento cumpliendo con la Definición de Terminado (SecciónDefinition 4.2Of - Sprint Backlog)Done).

3.3 - Daily Scrum (Scrum Diario)

El Scrum Diario es una reunión con un bloque de tiempo de 15 minutos paraque tiene el Equipopropósito de Desarrollo.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: ElLos Equipo de DesarrolloDevelopers y el Scrum Master

• ¿QuéAgenda se hace ende la reunión?

  n:

• El EquipoScrum Master y los Developers tienen la libertad de Desarrolloseleccionar respondela 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:

  preguntas a los Developers:
  • ¿Qué hice hoy?
  • ¿Qué haré mañana?
  • ¿Existe algún impedimento que estáesté afectando o nos pueda afectar?

• Consideraciones:

  • Durante el Scrum Diario el Equipo decoordina Desarrolloy 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

    Elmuy común que el Equipo de Desarrollo o los miembros del equipo a menudo se vuelvenvuelva 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.

    Equipo.

  • 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 delleve Desarrolloa tengacabo la reunión, pero esson ellos EquipoDevelopers delos Desarrollo el responsableresponsables 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 endentro losde límites delun bloque de tiempo de 15 minutos.

  • El Scrum Diario es una reunión interna del Equipo de Desarrollo.Equipo. Si otras personas están presentes, el Scrum Master se asegura de que no interrumpan la reunión.

    n ni alteren la planificación del trabajo.

  • Los Scrum Diarios mejoran la comunicación, eliminanidentifican la necesidad de realizar otras reuniones, identificanlos impedimentos arelacionados removercon relativosdesarrollo aldel desarrollo,trabajo, resaltan y promueven la toma rápida de decisiones y mejoran el nivel de conocimiento del Equipo de Desarrollo.

    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

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.

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.