Noticias

El marco de trabajo Scrum trajo consigo la popularización de una gran serie de artefactos para la auto-gestión. Entre estos encontramos los “radiadores de información”, que son considerados una herramienta descendiente del "control visual" del sistema de producción de Toyota.

Gráfico 1. Radiadores de información virtuales (Envato elements)

Los radiadores de información brindan la visibilidad necesaria para iniciar una conversación alrededor del proyecto o producto en construcción. Estos pueden ser números, dibujos o gráficos electrónicos, disponibles para ser vistos por el equipo, es por ello que usualmente son colocados en el mismo lugar donde este trabaja.

Estos radiadores favorecen a los proyectos en la medida que fomentan la transparencia, haciendo la información visible para los visitantes que pasen por el lugar. Internamente el equipo apoya esta transparencia asegurándose que la información es visible y veraz.

Algunos de los radiadores de información más populares son los Kanban boards, Scrum boards, burn up chart, burn down chart, entre otros.

Fig 2. Scrum Board (foto propia del autor)

Este último mencionado, el Burn down Charts o “gráfico de quemado” es el motivo del presente artículo y es uno de los radiadores de información más usados como complemento de Scrum. Su objetivo es permitir que los equipos conozcan su progreso respecto al trabajo pendiente.

A continuación, vemos un burndown chart extraído de un proyecto que además utiliza la herramienta Jira.

Fig3. Burndown chart (Elaboración propia de proyecto real)

En el gráfico de ejemplo encontraremos.

• En el eje vertical la medida de trabajo pendiente puede ser tareas, puntos de historia de usuario, entre otros.
• En la línea horizontal vemos nuestra medida de tiempo (horas, días, minutos, semanas, etc.)
• La línea de color rojo representa el progreso real en el tiempo

 Este tipo de gráficos nos ayuda a calibrar nuestro avance y visualizar de manera sencilla y concreta, el trabajo "real" terminado. Esto quiere decir que el burn down chart no muestra el trabajo en progreso, sino el pendiente y aquel que está por terminar.

En gestión de proyectos usualmente usamos porcentajes para reportar el progreso o avance, lamentablemente estos valores solo explican cuánto hemos avanzado, pero no necesariamente cuánto hemos terminado ya que acepta tareas sin terminar como parte de este porcentaje.

 Por ejemplo, si estamos construyendo un edificio de 5 pisos, 2 pisos y medio representan 50% de avance del proyecto. Pero, en términos “reales” solo hemos terminado 2 pisos.

El burn down chart por otro lado, nos cuenta nuestra realidad en base a las tareas completadas. Por ejemplo: Si quisiéramos construir una aplicación con diez funcionalidades, el burn down chart sólo descendería por funcionalidad terminada. Por otro lado, si usáramos porcentajes y nos dicen que vamos al 50% de la aplicación, podría significar que, de las 10 funcionalidades por hacer, hemos avanzado la mitad de cada una.

Patrones al leer un burn down chart

Trabajo en la última milla

Habíamos mencionado que el Burn down chart es ideal para generar una conversación. El gráfico que se muestra nos puede dar indicios de cómo estamos atacando el trabajo pendiente y evaluar si esta es la mejor manera de hacerlo.

Por ejemplo, si se nos presenta el siguiente gráfico en repetidas iteraciones

Fig 4 Burn Down Chart simulado

Podemos interpretar que la mayor cantidad de trabajo se está terminando solo en los últimos dos días. Esto nos llevaría a pensar que a lo mejor no estamos realmente logrando dividir el trabajo en partes lo suficientemente pequeñas que nos permita progresar diariamente.

Lo que nos dice este artefacto varía según la naturaleza del trabajo.

Por ejemplo, si estuviésemos usando este artefacto para una notaría nos diría que en estos 10 días (línea horizontal) trabajamos mayoritariamente trámites que requieren más de un día en terminarse. Por otro lado, si fuese un burn down sobre la producción de una fábrica de cervezas, nos llamaría a analizar por qué no se está manteniendo un ritmo estable de producción diaria.

Trabajo bloqueado

En caso se nos presente un gráfico como el siguiente:

Fig 5 Burn Down Chart simulado

Podemos inferir que algunos trabajos de este proyecto toman gran parte del tiempo o presentan grandes tiempos de espera. Puede ser este el tipo de trabajo con dependencias o bloqueos tales como aprobaciones, entrega de proveedores o trámites legales.

Posibles malinterpretaciones

Burn down chart tiene por objetivo mostrar el progreso de "quemado" o tareas terminadas. Escapa de su objetivo el poder mostrar cambios en el alcance del proyecto. Estas variaciones tales como re estimaciones o cambios imprevistos no son leídos de manera clara en el Burndown chart, para ello usamos otro gráfico llamado Burn Up Chart que sí nos permite ver estos impactos.

Un número extraíble del gráfico burn down chart es la velocidad del equipo, que es el promedio del trabajo completado entre el espacio de tiempo. Este número solo, no provee mucha información debido a la naturaleza del trabajo de conocimiento. Sin embargo, en ambientes más predecibles puede ser de gran ayuda. Por ejemplo, en contextos de fabricación industrial donde el performance depende mayoritariamente de una máquina.

Aplicaciones

Como hemos podido observar el burn down chart se puede usar en toda clase de proyectos que tengan un alcance estimado y un espacio de tiempo para ser ejecutado. Usualmente se usa por sprints en scrum pero también se puede usar para espacios de tiempo mayores como planes trimestrales o el tiempo de vida del producto.

A modo de ejemplo pueden descargar un archivo excel donde se genera automáticamente el burn down chart y pueden analizar sus resultados.

Archivo de ejemplo: https://1drv.ms/x/s!AnAt0YsxYjgXmfAeO7TZI3fChTInjA?e=eer1N2

Sobre el autor:

 

Gustavo Veliz Bernaola

Especialista en agilidad empresarial y desarrollo de equipos de alto rendimiento. Acompaña a múltiples empresas y equipos en la formación de equipos ágiles y desarrollo de juegos serios para el cambio cultural.
Ha trabajado en proyectos en Perú, Estados Unidos, Argentina y Chile, utilizando el framework scrum, prácticas de Extreme Programing y prácticas ágiles, logrando equipos de alto rendimiento. 
Es trainer en Scrum de Scrum Inc (empresa de Jeff Sutherland cocreador de Scrum).