Evento: Sprint

El Sprint es un contenedor para todos los demás eventos… Los Sprints son el corazón de Scrum, donde las ideas se convierten en valor. - Guía de Scrum

Scrum, al ser un proceso de desarrollo incremental y evolutivo, utiliza periodos consecutivos de tiempo corto para construir un producto, Incremento tras Incremento, para inspeccionar y adaptar frecuentemente tanto el producto como el proceso utilizado. A estos periodos de tiempo acotado, en Scrum, se los identifica como Sprints.

Todos los eventos de Scrum, Sprint Planning, Daily Scrums, Sprint Review y Sprint Retrospective, y todo el trabajo que sea necesario hacer para transformar los PBIs en un Incremento sucede dentro de un Sprint.

En general, Scrum recomienda una duración de Sprint de un mes o menos, siendo una o dos semanas lo más habitual que encontrarás en la industria.

Una de las decisiones que debes tomar al comenzar el desarrollo de un producto o al adoptar Scrum es la duración de los Sprints. Luego, mantendrás esa duración constante a lo largo del tiempo, lo que implicará que la duración de un Sprint no cambia una vez que sea establecida. Como excepción podrías considerar aquellas situaciones donde el equipo mismo decida probar con Sprints más largos o cortos. Esta decisión se basa principalmente en la volatilidad del contexto: mientras más volátil sea (negocio cambiante, necesidades desconocidas, tecnología que evoluciona, etc.) más corta será la duración del Sprint. Lo importante es recordar que se logra mayor ritmo y previsibilidad teniendo Sprints de duración constante.

Duración y objetivo fijos

Durante un Sprint, el Equipo Scrum podría atrasarse o adelantarse con respecto a su trabajo. En estos casos, la variable de ajuste será el alcance del Sprint, nunca su duración. Esto significa, en el caso de adelantarnos deberemos incrementar el alcance del Sprint agregando nuevos PBIs y reducirlo en el caso de retrasarnos, pero nunca acortar o alargar el tiempo de Sprint. Esta decisión de aumentar o reducir el alcance del Sprint es una potestad del Equipo Scrum y, por lo tanto, tomada entre los Desarrolladores y el Product Owner.

Como te comenté anteriormente, el Sprint Backlog contiene el plan del Sprint. A medida que se avanza, se descubre y se aprende durante el Sprint, ese plan podría alterarse sin alterar el Objetivo del Sprint. Los cambios en el plan son gestionados por los Desarrolladores.

Calidad no negociable

A partir de lo que acabo de contarte podrías deducir que, frente a imprevistos o impedimentos, la calidad nunca es negociable. El nivel de calidad de las entregas está determinado por lo que hemos llamado Definición de Terminado, la cual no se altera. Esto quiere decir que, si el Equipo Scrum se atrasa con respecto a lo que debe entregar, nunca va a probar menos o construir con menor calidad para poder entregar todo en el Sprint, sino que se abrirá un espacio de negociación a la interna del Equipo Scrum donde Desarrolladores y Product Owner decidirán cómo ajustan el alcance sin afectar el Objetivo del Sprint ni la Definición de Terminado.

Recuerda, el compromiso en esta instancia es construir un Incremento que logre el Objetivo del Sprint respetando la Definición de Terminado. El Equipo Scrum nunca debe comprometerse a entregar un número determinado de PBIs. Progreso durante el Sprint

El progreso durante el Sprint es seguido día a día por los Desarrolladores. Existe un evento diario del que te hablaré más adelante, Daily Scrum, donde se revisa si el estado actual del trabajo realizado nos conduce hacia el logro del Objetivo del Sprint. En caso de que eso no suceda, los Desarrolladores toman la decisión de adaptar el plan restante del Sprint para acercarse nuevamente al logro del objetivo.

Cancelación de un Sprint

Un Sprint puede cancelarse si el Objetivo del Sprint se vuelve obsoleto. Esto sucede cuando las condiciones del entorno cambian tan drásticamente que ya no tiene sentido que el Equipo Scrum siga trabajando en lo que está trabajando y necesite mover su atención a algo mucho más importante.

Como te comentaba anteriormente, el hecho de descubrir que no se llega a completar el trabajo del Sprint no es una razón válida para su cancelación dado que, aun construyendo un Incremento más pequeño que el esperado se podría lograr el Objetivo del Sprint.

La cancelación de un Sprint en una decisión que solo el Product Owner está en condiciones de tomar.