Burndown chart

De vueltas con una de las herramientas ágiles más habituales, el diagrama burn down o diagrama de quemado, lo que sería una traducción literal poco afortundada, que podéis encontrar en la wiki. Vamos en tal caso a empezar con su definición:

Es una representación gráfica del trabajo por hacer en un proyecto en el tiempo. 

Usualmente el trabajo remanente (Backlog) se muestra en el eje vertical y el tiempo 
en el eje horizontal. Por lo que el diagrama representa el trabajo pendiente, útil para predecir el trabajo pendiente.

Ejemplo de Burndown chart que podéis encontrar en la wiki.

Se trata de una herramienta útil para no perder el punto de vista global del proyecto. Partes de una estimación de punto /horas disponibles desde inicio. Y del límite temporal disponible. A cada Sprint sabes el número de puntos que deberías completar para llegar en plazo (media o backlog ideal en la gráfica superior)

A este gráfico se le suele dar dos usos:

• Product burndown - Visión global del producto, realizada a partir del product backlog
• Sprint burndown - Visión concreta de cada Sprint

Existen herramientas digitales que permiten ver Burndow chart, una de las más conocidas es GreenHopper

Podemos ver imágenes en los siguientes puntos de esta útil herramienta integrada con JIRA. 

 

Imágen del planning board, una herramienta que todavía no hemos utilizado en el blog y que, de no disponer de una herramienta digital, es posible que no lleguemos a utilizar.

El Task Board de GreenHooper muestra las tres columnas habituales como ya vimos en el artículo de StoryBoards

Imágen del Burndown Chart de GreenHooper, que permite ver si nos estamos desviando del plazo final del proyecto, la velocidad efectiva del equipo.
 

Por último el release board, que tampoco hemos explorado aún en el blog.

Las métricas

Estas herramientas nos deben permitir extraer insights de referencia para la salud del proyecto. Existen muchas, incluso infinitas como sucede con la analítica web, pero ¿cuales realmente nos ofrecen un valor? Pues como siempre depende de tu proyecto. Subjetivamente voy a enumerar las que más relevante me parecen a mi.

• Earned Value. % de completitud del proyecto respecto a los requerimientos iniciales del mismo. Es importante especificar que damos como valor completado, debería ser objetivos validados por el cliente/usuario final.

 

En la gráfica superior podemos ver la inversa del Earned Value (% still to go) y además como visualizamos en el burn down chart la aparición de tareas no previstas gráficamente.

•  Development Speed. Una de las variables más complejas de analizar (por la incertidumbre con la que trabajamos) pero de las más útiles nos va a permitir re-planificar el proyecto a futuro, y prever si existe una desviación para su finalización. De igual modo, nos va a permitir ver el grado de aprendizaje que está obteniendo el equipo ... así debería ser, debería incrementarse la velocidad de desarrollo.
• En función de alguna incidencia o necesidad concreta podemos necesitar más métricas, pero estas dos pueden ser suficientes. En alguna situación podemos valorar económicamente los objetivos y obtener una métrica ROI, pero no creo que estén necesariamente dentro del ámbito de la gestión, así que dejaremos esos puntos para artículos más especializados.

Saludos,