.
06/01/2017

Guía de uso paso a paso de los diagrama de quemado – burn charts

Monitoreo del avance

Los diagramas o gráfico de quemado se emplean en scrum para mostrar el progreso del equipo de trabajo. Pueden utilizarse tanto para mostrar el avance del proyecto como del sprint. También son muy útiles para para predecir la fecha aproximada de finalización del proyecto, y comprender las implicaciones de los cambios en el alcance. En este post te explico cómo hacerlo.

Diagrama de quemado “hacia abajo” y “hacia arriba”

Cualquier forma de presentar la información relativa al proyecto de manera visible se conoce en los entornos Ágiles como un “radiador de información”.  Pueden ser-grandes pantallas o tableros, aunque la mayoría equipos Ágiles optan por  hacerlo mediante tableros físicos.

Los diagramas de quemado pueden considerarse bien como un instrumento o una técnica. Permiten mostrar de manera sencilla en qué estado se encuentra el proyecto, contribuyendo con ello a aumentar la transparencia del proyecto.

01 Diagramas de quemado

Un gráfico de quemado hacia abajo (burn-down chart) muestra la cantidad de trabajo restante, por lo qué la línea de rendimiento/avance va hacia abajo. Por el contrario el diagrama quemado hacia arriba (burn-up chart) muestra la cantidad de trabajo realizado: la línea que muestra el avance va hacia arriba. En ambos casos cuanto más pronunciada se la pendiente de la línea de avanza, a mayor velocidad estaremos avanzado, “quemando puntos de historia del proyecto”.

¿Cuál emplear?

Aunque ambos son muy similares, en mi opinión el burn-up chart  permite una visión de evolución constante del proyecto. Es decir, con este diagrama es más fácil mostrar los cambios en el alcance del proyecto (Backlog de producto).

También es más fácil hacer comprender a nuestro cliente cuando nos acercamos peligrosamente a una fecha límite, que la funcionalidad en riesgo será la qué menos valor aporte en comparación a lo ya entregado.

¿Cómo desarrollar un diagrama de quemado hacia abajo?

Paso 1. Diseñar la gráfica

Para desarrollar un diagrama de quemado necesitamos una gráfica: en el eje horizontal representaremos la duración del proyecto, medido en sprints. Recuerda que todos los sprints deben tener la misma duración.

En el eje vertical representaremos el Backlog del producto, el alcance del proyecto que habremos estimado previamente en puntos de historia. Después, se traza una línea paralela al eje horizontal que utilizaremos para estimar la fecha de finalización del proyecto, y para visualizar los cambios en el alcance del proyecto.

02

Paso 2. Monitorear el progreso

Para monitorear el avance del proyecto debemos ir agregando el número de puntos de historias finalizados tras cada sprint. Al respecto recuerda que solo debemos considerar los puntos de historia de las historias de usuario que el equipo de desarrollo haya completado al 100% de acuerdo con la Definición de Hecho.

03 Diagrama de Quemado - Monitoreo del progreso

Sprint tras sprint, o día a día si  monitoreamos el progreso del sprint, el avance del equipo de desarrollo irá dando forma a una línea con pendiente “hacia arriba”. La pendiente se corresponde con la velocidad a la que estamos “quemando” el Backlog de Producto. Mejor dicho: los puntos de historia del Backlog de producto, de ahí el nombre de “burn-up chart”.

Paso 3. Monitorear los cambios en el alcance

Una de las ventajas de ese sencillo diagrama es que también nos permite monitorear los cambios en el Backlog de Producto. Esto no debería aplicar para el Backlog del Sprint, dado que cómo ya deberías saber el Backlog del Sprint se congela una vez iniciado el sprint.

04 Diagrama de quemado - Modificación del alcance

Como puedes ver en la gráfica siguiente representar los cambios en el Backlog de Producto es realmente sencillo.

¿Para qué y cómo utilizar un diagrama de quemado hacia abajo?

1. Estimar la fecha de finalización

Para poder predecir la fecha de finalización del proyecto en base  al diagrama de quemado es conveniente esperar al menos 4 o 5 sprints. Hasta entonces, el equipo de trabajo no habrá alcanzado una velocidad más o menos constante. Además, durantelos primeros sprints siempre se concluirán menos puntos de historia: el equipo tiene que conocerse y conocer el proyecto.

¿Cómo estimar la fecha de finalización? Sólo hay que proyectar la línea de puntos de historia entregados y calcular dónde se cortará con la estimación del Backlog de Producto. Fíjate en el ejemplo:

05 Diagrama de Queamado - Estimaciones

Al respecto ten en cuenta varias consideraciones:

Uno. La proyección que hacemos está basada en la velocidad actual del equipo, pero NO podemos predecir el futuro con una certeza del 100%. Para solucionarlo podríamos incluir un rango de probabilidades,  que es lo que muestran las líneas naranjas en la imagen anterior.

06 Diagrama de Quemado - Probabilidades

Dos. La predicción de la fecha de finalización se basa el Backlog de Producto actual. Cualquier modificación sobre este afectará la fecha de finalización prevista.

Tres. Al inicio del proyecto no tendremos datos para realizar una primera estimación. En ese caso, podemos recurrir a una estimación “idealizada” que deberías presentar en otro color. De esta manera se diferenciará de aquella que hagamos en base a los datos reales.

Para considerar las versiones

Hasta ahora en el eje vertical hemos representado la estimación del Backlog de Producto de la versión actual. La buena noticia es que también podemos representar la estimación para cada una las diferentes versiones que tenemos previstas.

07 Diagrama de Quemado - Versiones

Consideraciones finales

Recuerda: la estimación se hace con incertidumbre y podemos reducirla, pero no eliminarla completamente. Lo único qué podemos hacer al respecto es centrarnos en entregas “pequeñas” y buscar un ritmo sostenible del equipo.

Post relacionados

Time box En los entornos Agiles un concepto fundamental es  el de bloques de tiempo (time box). Se refiere a: 1) una cantidad predefinida y fija de ti...
6 cuestiones básicas acerca de LEGO Serious Play LEGO® Serious Play® (LSP) se basa en la creencia que las soluciones están dentro de los equipos de trabajo de las organizaciones, y de que todo el mun...
7 ventajas de gamificar la gestión de proyectos Las últimas estadísticas muestran que solo uno de cada tres proyectos se cumplen a tiempo y dentro del presupuesto acordado, sobre todo, por la falta ...

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

AUTOR:  Juan Luis Vila Grau

PRINCE2® practitioner, Scrum Master (PSMI), EXIN Agile Scrum Foundation, AgilePM® Foundation, Management_of_Risk (M_o_R®) Foundation. and an enthusiastic of Agile management. Especialistas en técnicas participativas para la gestión de proyectos, y en el Enfoque del Marco Lógico (EML). Faclilitador certificado en el método LEGO® Serious Play®

Utilizamos cookies de terceros para mejorar nuestros servicios. Si continúa navegando, considera que acepta su uso. Más información aquí.  CERRAR