Rituales o Eventos de SCRUM

La dinámica de SCRUM se implementa a través de ceremonias o rituales caracterizadas por eventos de duración predeterminada (Time-box), que le dan al desarrollo un ritmo sostenible, con entregas frecuentes de software valioso y oportunidades frecuentes de inspección, adaptación y transparencia. Cada evento en forma de reunión, tiene un objetivo con una duración máxima que depende del tamaño del Sprint, que se puede acortar si se logra antes dicho objetivo. Solo el Sprint tiene una duración fija. El SCRUM Master se asegura que el equipo comprende, realiza y logra el objetivo de cada evento en el tiempo especificado.

Los rituales de SCRUM mejoran la comunicación entre los miembros del equipo y con ello su nivel de conocimiento, asimismo, promueven el cumplimiento del objetivo del Sprint ya que facilita procesos ágiles de aprendizaje, toma de decisiones y solución de problemas.

El Sprint es el núcleo de SCRUM en el que se desarrolla y entrega un incremento del producto. Tiene una duración entre 1 y 4 semanas, siendo 2 o 3 semanas la duración más común. Considerando la complejidad del desarrollo, la volatilidad del negocio, la tecnología y la madurez del equipo,  el equipo SCRUM decide el tamaño fijo que tendrán los Sprint. Si la meta fijada para el Sprint se logra antes, o no se pudiese alcanzar, el equipo podría ajustar el alcance del Sprint, pero no se modifica su tiempo de duración. Cada Sprint contiene los demás eventos.

Los eventos de SCRUM incluyen: la reunión de Planificación del Sprint (Sprint Planning Meeting), las reuniones Diarias (Daily Scrums), la Revisión del Sprint (Sprint Review) y la reunión de Retrospectiva (Sprint Retrospective). Adicionalmente, el equipo puede realizar 1 o 2 reuniones de Refinamiento del Product Backlog (Product Backlog Refinement o Grooming) para colaborar con el Product Owner en el mantenimiento y detalle del Product Backlog.

En el Sprint Planning todo el equipo colabora para seleccionar los PBI (Product Backlog Item) priorizados que se desarrollarán durante el Sprint y fijar la meta del mismo. Los PBI deben ser lo más independientes posible, los más dependientes podrían agruparse en uno. 

El Sprint Planning dura máximo 8 horas en Sprint de un mes. Se divide en 2 partes, la primera donde el Product Owner explica los detalles funcionales de los PBI prioritarios, responde las preguntas del equipo de desarrollo y junto al equipo se seleccionan los PBI a desarrollar y la meta del Sprint. En la segunda parte, se suele retirar el Product Owner, y el equipo acompañado del Scrum Master, establece cómo se realizará el trabajo, define un diseño general, identifica tareas técnicas y llega a acuerdos de alto nivel que se detallarán durante el desarrollo del Sprint. El resultado del Sprint Planning es el Sprint Backlog que se coloca en una pizarra de tareas (Taskboard), física o digital, visible para todos.

El Equipo de Desarrollo es quien realiza la estimación de esfuerzos. Puede utilizar la técnica de Planning Poker para realizar una estimación inicial por consenso donde cada miembro  comparte su opinión y estimación. También se suele utilizar información sobre la velocidad y capacidad productiva del equipo obtenida en Sprint anteriores. En SCRUM la estimación es un pronóstico  potencial que se basa en el compromiso que adquiere el equipo para lograr el objetivo del Sprint.

Las reuniones Diarias (Daily Scrums), son reuniones cortas que el equipo de desarrollo debe realizar todos los días, de solo 15 minutos, para asegurar la comunicación, coordinación de actividades y la colaboración entre los miembros del equipo. Los Daily permiten al equipo evaluar actividades, compartir dificultades y tomar decisiones de planificación, en tiempo real, promoviendo los pilares de Scrum de Transparencia, Inspección y Adaptación.

Se realizan siempre a la misma hora y en el mismo lugar. Es conducida por el Equipo de Desarrollo, el Scrum Master puede facilitar la dinámica para garantizar se mantenga la reunión dentro de su propósito y duración. Puede asistir el Product Owner y otros involucrados en calidad de observadores, sin embargo, no deben intervenir en la discusión, ni solicitar justificación del progreso o explicaciones a los problemas. No se debe usar para dar Status a ninguno de los roles.

Cada miembro del equipo de desarrollo responde a 3 preguntas: 1. ¿Qué hice desde el último daily? 2. ¿En qué voy a estar trabajando?, y 3. ¿Qué problema o impedimento tengo para alcanzar el objetivo?.  Los problemas no se resuelven en el daily, sino en revisiones posteriores. El Scrum Master asegura que estas revisiones se realicen a la brevedad y los problemas sean resueltos con prontitud.

Al finalizar el Sprint se realiza una reunión de revisión (Sprint Review), donde el equipo de desarrollo presenta al Product Owner e involucrados, el resultado funcional del incremento. Estos lo aceptan o rechazan dando retroalimentación al equipo de desarrollo. Si el elemento (PBI) es rechazado, reingresa al Product Backlog con alta prioridad, para ser tomado en el próximo Sprint; a menos que el Product Owner cambie la prioridad del elemento. El Scrum Master facilita la reunión, asegurando que cumpla su objetivo dentro del tiempo estimado, que en Sprint de un mes, es máximo de 4 horas.

Luego del Sprint Review y antes del Sprint Planning del próximo Sprint, se realiza una reunión de Retrospectiva (Sprint Retrospective), que permite al equipo reflexionar sobre cómo se realizó el trabajo, identificar y analizar los acontecimientos positivos y negativos para el cumplimiento del objetivo del Sprint. El resultado principal de esta reunión es lograr en consenso acciones de mejora para ser implementadas en el próximo Sprint, asegurando con ello la mejora continua y la implementación de prácticas emergentes en los procesos del equipo de desarrollo. Estas acciones y su impacto se revisan en la próxima reunión de retrospectiva. Cómo en los otros eventos, el Scrum Master facilita la reunión, asegurando que cumpla su objetivo dentro del tiempo estimado, que en Sprint de un mes, es máximo de 3 horas.

Por último, a fin de mantener el Product Backlog priorizado y los PBI próximos a desarrollarse detallados, el Product Owner y el Equipo de desarrollo suelen ejecutar 1 o 2 reuniones de refinamiento (Product Backlog Refinement o Grooming) en cada Sprint, donde se añaden, retiran, detallan y estiman los elementos del Product Backlog del siguiente Sprint. Es una reunión corta, generalmente de 1 hora, conducida por el Product Owner, con el apoyo del Scrum Master quien asegura que la reunión cumpla su objetivo en el tiempo establecido.

Un aspecto de gran relevancia para el éxito de cualquier proyecto de desarrollo de software, es la forma en que se describen los requerimientos o requisitos del producto en el Product Backlog, siendo la técnica más utilizada las historias de usuario. Sobre este tema escribiré en el próximo artículo.

Gracias por leerme.-