¿Qué hacer cuando el equipo nunca cumple con la pila de sprint?

Gráfico burn-down con un sprint subestimado

Partimos de la base de que tenemos un equipo formado y motivado, que lleva unos pocos sprints a su espalda y que ha alcanzado un cierto grado de autoorganización. Todo debería ir bien, pero con cada sprint se obtiene un gráfico burn-down con un patrón semejante al de la imagen de la derecha, en que se pone de relieve que las tareas de las planificación del sprint se han subestimado o han aparecido nuevas tareas que no se han visto antes durante el sprint.

Podríamos seguir nuestra intuición y razonar que dado que cada sprint se ha se alargado, que el equipo necesita más tiempo y la solución estaría en alargar el tiempo de los sprints. Pero eso sería erróneo, ya que si el equipo está fallando repetidamente a no llegar a final de sprint con todo terminado algo no está funcionando en la estimación. Contrariamente a ese primer impulso, lo que hay que hacer es reducir el tiempo de los sprints, hacerlos más pequeños. Con ello se obliga al equipo a tomar menos historias de usuario y crear tareas más pequeñas, y cuanto más pequeña sea una tarea menos incertidumbre hay en su estimación, y por tanto más certidumbre para terminar el sprint en el tiempo establecido.

Tareas y sprints más pequeños tienen una segunda ventaja que también ayuda a cumplir los sprints y es que focalizan al equipo. Una de las constantes en los métodos ágiles, como en Scrum, es que sus iteraciones cortas y frecuentes, sus reuniones diarias y en general sus ciclos cortos mantienen el foco del equipo en lo que le da valor al proyecto.

Como tercera ventaja mencionar que cuanto menor sea el sprint más se solapan las tareas y el equipo estará diseñando, programando y probando de manera no secuencial, casi a la vez, lo que implica máxima colaboración e interacción entre los miembros del equipo, propiciando equipos multidisciplinares y autoorganizados.