¿Cómo controlar el trabajo de los proyectos ágiles con Burndown Chart?

Cuando se dispone de un plan detallado de actividades en las que se identifica tanto el inicio como el final de las mismas y su secuenciación, podemos usar herramientas de planificación tradicionales como los diagramas de Gantt. Éstos son realmente útiles y sirven como herramienta de comunicación para los diferentes agentes que van a participar en el desarrollo del proyecto, a la vez que permiten disponer de un grado de detalle tan alto como sea necesario.

La cuestión surge cuando queremos trabajar en un entorno más ágil, donde no es tan importante disponer de esta información. De hecho, lo que necesitamos saber es si la estimación del trabajo que se ha pensado que el equipo va a desarrollar en el sprint, es la adecuada, si la van a cumplir y poder monitorizarla durante el proceso. En estos casos, lo ideal es disponer de una herramienta sencilla que pueda utilizarse de forma intuitiva y que ofrezca la mínima información necesaria para los fines expuestos anteriormente.

¿Qué es el burndown chart?

Podemos definirlo como un gráfico que muestra la cantidad de trabajo pendiente de realizar por el equipo en el sprint actual. Muestra el progreso realizado por el equipo, comparándolo con la planificación ideal. De forma que se puedan detectar estimaciones de esfuerzo incorrectas lo antes posible, y así poder tomar decisiones tempranas sobre las acciones correctivas a implementar.

Éste gráfico tiene los siguientes 4 componentes principales:

1. La cantidad de trabajo a completar por el equipo en el sprint: Se marca en el eje de coordenadas. Lo más importante en este punto es mantener siempre un mismo criterio a la hora de valorar –estimar- el trabajo a realizar; se pueden utilizar puntos (Story points), horas ideales, etc. Personalmente, me gusta utilizar puntos. De forma que el equipo, a partir de la adopción de una actividad base –que todo el mundo conoce-, y que se valora –por ejemplo- como 1, va realizando estimaciones comparativas. Así, si se considera que la nueva actividad a estimar supondría un esfuerzo de, más o menos, el doble, se valoraría como 2. En la fase de planificación del sprint, se estiman las actividades a realizar dentro del mismo y se suman, de forma que se disponga de un número (estimación total del esfuerzo del sprint), que será el objetivo a cumplir en el sprint.

2. La duración del sprint. En el eje de las abcisas, colocaremos los días del sprint. Es una muy buena práctica, unir el control del trabajo en el sprint con la reunión diaria (stand up daily meeting) del equipo. De forma que cada día, se actualice el trabajo realizado a través, por ejemplo, de uso de un tablero Kanban o tablero Scrum. En este momento, cada miembro del equipo, podrá actualizar sus tareas, moviéndolas desde TO DO a DOING o DONE, sirviendo esta información para actualizar el trabajo realizado.
3. Línea de trabajo ideal. Una vez que hemos construido el esqueleto del gráfico con el trabajo total a realizar y los días del sprint, podemos dibujar una línea que una el trabajo total con el último día del sprint. Ésta mostraría el rendimiento ideal del equipo.
4. Evolución del trabajo del equipo. Finalmente, como hemos indicado en el punto 2, cada día se debe ir restando del trabajo total inicial, la cantidad de trabajo ya finalizado en el sprint. De esta forma, podremos ver si el equipo está obteniendo el rendimiento planificado (si coincide con la línea de trabajo ideal), es más eficiente (Si va por debajo), o al contrario va por arriba, lo que no sería una buena noticia ya que el rendimiento sería menor que el estimado y, probablemente no será posible completar todo el trabajo deseado en el sprint.

¿Se puede añadir trabajo a un sprint?

Y qué pasa cuando en un sprint el Product Owner pide que se incorpore trabajo extra; la solución debe ser clara:

• Si puede esperar, se dejará para el siguiente sprint, debiendo el Poduct Owner actualizar la pila de producto (Priotized Product Backlog).
• Si no puede esperar y es tan importante que va a hacer que el trabajo realizado en el sprint no sirva, entonces se debe interrumpir el sprint y re-iniciar uno nuevo.

Otra cuestión es cuando el equipo, durante el sprint, identifica nuevas actividades –más esfuerzo- para completar el trabajo comprometido en el mismo. Hay que resaltar la diferencia entre las dos situaciones, ya que en la que acabamos de exponer, no se añaden funcionalidades extras, ni se admiten cambios sobre el trabajo comprometido del sprint. En este caso es posible modificar el trabajo total del sprint incorporando es esfuerzo extra necesario.

Hay una variación de este gráfico que es el Burnup Chart. La diferencia fundamental estriba en cómo se muestra el trabajo; en este caso, éste se va acumulando y las dos líneas (planificado y real) convergen en la parte superior. En este tipo de gráficos, también se puede indicar la modificación del trabajo incluido en el sprint siguiendo lo expuesto en el párrafo anterior.

¿Qué hacer cuando el equipo va más lento o más rápido?

Es posible que el equipo vaya más deprisa de lo planificado, obteniendo un mayor rendimiento, de forma que podría darse el caso de que se terminase el trabajo antes de la fecha fijada como final del sprint. Es muy importante en Scrum mantener el ritmo y cumplir los compromisos, por lo que deberíamos, también, mantener las fechas de revisión del sprint. La solución: tener en la recámara trabajo suficientemente planificado (historias de usuario), fuera del sprint, de forma que se puedan incorporar al sprint actual y así no afectar al ritmo del mismo.

En cambio, si el rendimiento no es el previsto y no se alcanzan los objetivos planificados, la priorización es la respuesta. Así, el equipo debe focalizarse en terminar el trabajo más importante y prioritario del sprint, según la perspectiva del Product Owner, de forma que, si queda algo por completar, que sea lo menos importante. Una buena práctica es la de identificar en el sprint varias historias de usuario, ya que, si no se hubiese descompuesto el trabajo suficientemente o las historias fuesen demasiado grandes y pocas, podemos tener el riesgo de no entregar nada, lo que sería un fracaso importante para el equipo.

La información generada será usada por el equipo para los siguientes sprints, ayudando a determinar la capacidad del equipo y afinando, por tanto, más las estimaciones de trabajo que es posible realizar por éste.

Una buena herramienta

Hemos analizado cómo usar el Burndown Chart y como hemos visto, es una herramienta muy útil, intuitiva y que sirve para conectar el trabajo del equipo con la planificación comprometida y que se debe usar junto con otros artefactos como los tableros Kanban y las reuniones de equipo. Así, sin duda, es una gran herramienta de comunicación que ayuda a que se pueda valorar el progreso del trabajo del equipo en el sprint y fomentar la proactividad.

Si te interesa profundizar más en el uso de artefactos ágiles y la gestión de proyectos con SCRUM disponemos de cursos especializados como el que puedes encontrar en el siguiente link: Gestión de proyectos ágiles con Scrum.