Cancelación anticipada, por regla general, en los enfoques ágiles con iteraciones, no se acepta ningún cambio dentro de la iteración o el Sprint en curso. Cualquier cambio que surja se puede reflejar en la Pila de Pendientes de Producto (Product Backlog), pero no en la iteración en curso.

Sin embargo, en el caso en que se presente un cambio que impacte fuertemente en la iteración que se esté desarrollando, esta puede cancelarse antes de que el bloque de tiempo llegue a su fin.

Solo el Dueño de Producto (Product Owner) tiene la autoridad para cancelar la iteración o el Sprint, aunque puede hacerlo bajo la influencia de los interesados, del Equipo de Desarrollo o del Scrum Master.

Una razón válida por la que la iteración se podría cancelar podría ser que el objetivo de la iteración se haya vuelto obsoleto por alguna circunstancia, ya sea un cambio de requisito, cambio de entorno u otra situación.

Esto podría ocurrir, por ejemplo, si la compañía cambia la dirección o si las condiciones del mercado o de la tecnología cambian.

Sin embargo, debido a la corta duración de las iteraciones o Sprints (en el Framework Scrum), su cancelación rara vez tiene sentido.

Cuando se cancela una iteración se revisan todos los elementos de la Pila de Pendientes del Producto que se hayan completado y “Terminado”. Si una parte del trabajo es potencialmente entregable, el Dueño de Producto normalmente la acepta.

Todos los Elementos de la Pila de Pendientes del Producto no completados se vuelven a estimar y se vuelven a introducir en la Lista de Producto. El trabajo finalizado parcialmente en estos elementos pierde valor con rapidez y por lo general se debe volver a estimarlo.

Las cancelaciones de Sprint consumen recursos ya que todos los integrantes del equipo del proyecto se reagrupan en otra Planificación de Iteración para continuar con el trabajo más prioritario. Además, las cancelaciones suelen ser traumáticas para el equipo, por lo que se trata de que sea algo excepcional.

Autora: Cecilia Boggi