CANCELAR O NO CANCELAR UN SPRINT

Sin duda la “Guía Scrum” es muy reservada sobre el hecho de cancelar un Sprint y sobre la autoridad del Product Owner para realizar dichas cancelaciones.

Digamos que podemos partir de la base de que la cancelación de un Sprint sólo debe producirse cuando la meta que nos hemos marcado queda obsoleta.

"Las cancelaciones de Sprint son a menudo traumáticas para el equipo Scrum, y son muy poco comunes." - La Guía Scrum.

Un Sprint no se cancela porque sí, porque por ejemplo el equipo que no pueda cumplir los elementos que hayan sido marcados como objetivo. La única razón es la obsolescencia de la meta marcada para el Sprint y eso puede ocurrir por diversos motivos:

• Hay algo más valioso o urgente que requiere que del completo compromiso y enfoque del equipo.

• Hay un cambio de rumbo en el producto o en el contexto del mismo que hacen irrelevantes los compromisos adquiridos para el Sprint.

• Los Sprints son demasiado largos y las cambiantes condiciones de mercado hacen de las cancelaciones la única manera de responder a las mismas.

• La meta del Sprint no es compartida por los stakeholders o sponsors.

En el caso de una cancelación, el equipo de Scrum se reúne para planear cómo adaptarse en consecuencia. 

Sin embargo, la cancelación presenta algunos desafíos.

¿Qué hacer con el trabajo en curso?

"Todos los artículos incompletos del Sprint Backlog se vuelven a estimar y se vuelven a poner en la Product Backlog. El trabajo que se hace con ellos se deprecia rápidamente y debe ser frecuentemente reestimado". - La Guía Scrum

Los elementos del Sprint Backlog han de ser actualizados para que el trabajo realizado emerja y se haga transparente. Cierto es que cuanto más tiempo pase, el trabajo realizado irá quedando obsoleto, adquirirá probablemente una cantidad incremental de deuda técnica, por lo que irá siendo cada vez menos relevante. En algún momento tendremos que tomar la decisión de completar el trabajo pendiente o desechar todo.

En estos casos caeremos a menudo en la tentación de considerar la cancelación de un Sprint cuando nos encontremos con bloqueos fuertes, con temas que por su alta complejidad no nos permiten avanzar adecuadamente o porque estamos recibiendo feedback del equipo de que no creen ser capaces de finalizar los trabajos comprometidos a tiempo. Estos no son escenarios en los que la cancelación de Sprint sea un escenario válido. El foco y el objetivo del Sprint siguen intactos y podemos adaptar el plan para lograr al menos aquello que seamos capaces de acometer.

Otro escenario en el que no debemos contemplar una cancelación de Sprint es en el caso de acabar con todo lo comprometido para el objetivo del Sprint. En este caso debemos absorber más trabajo, generalmente focalizando en deuda técnica, hasta completar el tiempo definido para el Sprint.

¿Qué hacer con el trabajo ya "hecho"?

"Cuando se cancela un Sprint, se revisan todos los ítems del Product Backlog completados y "Hechos". Si parte del trabajo es potencialmente publicable, el Product Owner lo acepta". - La Guía Scrum.

En caso de cancelar un Sprint, un tema escabroso es qué hacer con los elementos considerados como ya hechos.

Simplemente el determinar si el elemento está “hecho” y es “publicable”, puede ser una tarea realmente compleja. Podemos encontrarnos con dependencias sobre trabajo “no hechos” que invaliden el carácter de “publicable” de lo ya “hecho”. 

Otro reto al que nos enfrentamos en la cancelación del Sprint para el trabajo “hecho”, es cómo y cuándo abordamos su revisión. ¿Dentro y antes de cancelar el Sprint? ¿En el siguiente Sprint? ¿Cuándo se aborde el elemento en el futuro?

En cualquier caso, este es otro ejemplo de las complejidades añadidas que introduce una cancelación.

La Cadencia Sprint

"El corazón de Scrum es el Sprint" - La Guía Sprint

El latido de Scrum es el Sprint. A priori cuanto más consistente y constante sea el ritmo, mejor para el equipo y el producto. La consistencia reduce la complejidad.

La cancelación de un Sprint, se entromete con esta consistencia. La falta de consistencia pues, introduce complejidad al proceso. 

Personalmente creo que es muy valioso tener una retrospectiva en caso de cancelación. 

Una cancelación es también una oportunidad para que el equipo inspeccione y se adapte.

Residuos

"Las cancelaciones Sprint consumen recursos" - La Guía Scrum

A priori se puede pensar en las cancelaciones como un desperdicio, sin embargo, este evento también nos puede ayudar a prevenir el desperdicio. En cualquier caso, al cancelar Sprints, hay que tener en cuenta que la productividad, la estabilidad y la previsibilidad disminuirán temporalmente. 

En conclusión, mucho cuidado con las cancelaciones de Sprint tomadas a la ligera. Cuando nos entre la tentación de si cancelar o no un Sprint, hagamos la reflexión teniendo en cuenta todos los factores involucrados y afectados en tal decisión e intentemos mantenernos fieles a la Guía Scrum. Cancelemos un Sprint cuando la meta del mismo haya quedado obsoleta y asegurándonos, aun así, que los beneficios a obtener superan a los problemas generados.

Cancelar o no Cancelar, he aquí la cuestión.