Burndown y burnup para el Scrum Master

El burndown chart y el burnup chart son dos potentes herramientas para medir el avance del sprint y del incremento de producto respectivamente. Pero, ¿qué le aportan a un Scrum Master?

Comencemos con el burndown chart. Este gráfico nos muestra el trabajo pendiente para el sprint. En el eje X, horizontal, tenemos la escala de tiempo en intervalos regulares; y en el eje Y, vertical, tenemos el trabajo pendiente en las unidades de estimación que utilice el equipo. Al principio del sprint tenemos el punto más alto y debería ir disminuyendo hasta alcanzar el 0 muy próximo al final de sprint. Por eso, este diagrama debería actualizarse diariamente. En nuestra opinión, la Daily es un buen momento para hacerlo ya que además es un buen hilo conductor para diseñar el plan de trabajo para hoy.

¿Qué tipos de burndown chart podemos encontrar?

  • En ocasiones nos encontramos con equipos que cuando comienzan a trabajar bajo Scrum su burndown chart permanece casi inmóvil durante los primeros sprints (Figura 1). La principal causa es la ausencia de entrega continua y deberemos enfocarnos para conseguirla en los siguientes sprints.
BURNDOWN1

Figura 1: Burndown chart de primer sprint

 

  • A veces suele ocurrir que el gráfico permanece inmóvil hasta el día de la review en la que se entregan todos los items (Figura 2). Es una evolución del caso anterior y deberíamos seguir impulsando la cultura de entrega continua.
BURNDOWN2

Figura 2: Burndown chart con entrega final

 

  • Cuando los equipos ya entregan de forma continua, podemos encontrarnos con grandes escalones a lo largo de la pendiente (Figura 3). Esto nos suele indicar que se entregan elementos demasiado grandes que son susceptibles de dividirse en elementos más pequeños.
BURNDOWN3

Figura 3: Burndown chart con entregas grandes

 

  • Por último tenemos el caso en que se añadan nuevos elementos al Sprint Backlog en un sprint en curso. Lo puedes encontrar reflejado como un pico ascendente (Figura 4). Aquí deberíamos plantear una conversación junto al equipo y al Product Owner para conocer los motivos por los que ha entrado ese nuevo PBI, si pone en riesgo la consecución del objetivo del sprint y qué elementos menos prioritarios corren el riesgo de no completarse .

 

BURNDOWN4

Figura 4: Burndown chart con nuevos elementos 

Mantener un buen histórico de burndown chart puede ayudarte a detectar patrones en tu equipo. Te recomendamos que dediques un poco de tiempo a analizarlos y utilízalos en las retrospectivas para potenciar la mejora continua del equipo.

 

El Burnup Chart

Pasemos ahora al burnup chart. En este gráfico se representa la cantidad de producto entregado (incremento) en cada sprint de forma acumulada. En el eje X, horizontal, tenemos la escala de tiempo en intervalos regulares; y en el eje Y, vertical, tenemos el incremento en las unidades de estimación que utilice el equipo. De esta forma, podemos establecer cómo de lejos estamos para entregar un proyecto al completo. Aunque esta información es muy relevante para el Product Owner, el Scrum Master también puede extraer información valiosa de este gráfico.

¿Qué tipos de burnup chart podemos encontrar?

La forma ideal de un burnup chart es una pendiente constante ascendente que representa la entrega continua del equipo. Sin embargo, podemos detectar algunos comportamientos viendo el gráfico:

 

  • Si es común que tu equipo alterne entregas de un gran incremento con otras sin apenas modificación, puedes encontrar un burnup grandes pendientes y a continuación un periodo sin apenas cambios (Figura 5).
BURNUP1

Figura 5: Burnup chart entregas alternas

 

  • Si después de cada sprint la distancia con la recta ideal va aumentado está indicando que la entrega completa del proyecto se está retrasando en el tiempo (Figura 6). Presta atención a las proyecciones a partir de los últimos sprints para verificar que el retraso no comprometa una posible fecha de entrega final.
BURNUP2

Figura 6: Burnup chart con entrega comprometida

 

  • Un caso interesante en un burnup chart es un equipo que empieza con una nueva tecnología, proyecto, área de conocimiento, … Al principio se distancian de la recta ideal pero según avanzan los sprints, la desviación comienza a corregirse (Figura 7).
BURNUP3

Figura 7: Burnup chart con curva de aprendizaje

 

En resumen:

Con el burndown chart obtenemos una visión del trabajo pendiente en el sprint. Representamos los días del sprint frente al incremento de producto entregado cada día.

Con el burnup chart visualizamos el progreso de nuestro producto y la distancia hasta el producto completo. Representamos los sprints y el incremento acumulado en cada sprint.

El uso de estos radiadores de información para la mejora continua del equipo responde a los pilares de Scrum: inspección, adaptación y transparencia. Aunque podemos establecer acciones a partir de la información que se visualizan, te recomendamos que los utilices como inicio de una conversación con el equipo Scrum: por ejemplo, como guión para las dailys o como datos de entrada para una retrospectiva. El punto de vista de todo el equipo añade el contexto a la información obtenida de los gráficos con los que podréis tomar las acciones necesarias para potenciar la mejora continua del equipo.

También te puede interesar.

La historia de scrum, su primera implementación

Actualmente Scrum es el marco de trabajo más utilizado para implementar modelos Agile. Hoy os contamos como era su primera versión.

Es importante usar Historias de Usuario

Usar Historias de Usuario es importante para los Product Owner, además de la más utilizada a la hora de escribir el Product Backlog.

Cómo facilito una retrospectiva si no soy Scrum Master

Una buena retrospectiva da la oportunidad al equipo de analizar su funcionamiento y establecer mejoras. Te dejamos consejos para facilitarla.

Ventajas de aplicar el Lead Time en los Equipos Scrum

En ocasiones, cuando arrancamos con los Equipos Scrum, nos encontramos con un par problemas habituales: el tamaño de los PBIs y que trabajan en paralelo en todas los PBIs del sprint. Hoy te traigo una solución que hemos puesto en marcha en algunos Equipos Scrum de nuestros clientes.

Entender a los Equipos Scrum desde las Métricas

En nuestro trabajo diario con los equipos Scrum, es importante entender qué está ocurriendo sprint a sprint, y en qué lugares debemos poner el foco de las acciones de mejora de los equipos. También es importante disponer de datos objetivos, que en las sesiones de retrospectiva o de revisión del proceso, nos ayuden a tomar decisiones basadas en la realidad, y no en sensaciones u opiniones subjetivas.

El Product Owner: el desconocido y olvidado

Desde hace tiempo tengo la sensación que se desconoce la función de un Product Owner.

Monta equipos Scrum de éxito

Cómo montar equipos Scrum de éxitoYa sabes lo que es un equipo Scrum. Es hora de dar un paso adelante y entender cómo montar un equipo Scrum de éxito. ¿Qué tipo de perfiles incorporas? ¿Cómo se balancean? ¿Cuándo les incorporas? Son preguntas que probablemente te...

Scrum para disipar incertidumbre

Scrum es un marco que te puede servir para hacer lo mismo de siempre a trocitos. Sin embargo, puedes utilizar Scrum de manera inteligente y sacarle toda su potencia. ¿Cómo? Orientándolo a generar certezas sobre tu producto o tu mercado.

El uso de las Métricas para saber nuestro nivel de Incertidumbre

Scrum nos ayuda a manejar la incertidumbre. Pero ¿cómo sabemos que lo estamos consiguiendo? ¿Qué métricas pueden ayudarnos a confirmar que tenemos bajo control la incertidumbre?

El Product Owner y su relación con los Stakeholders

Como Product Owner enseguida te has dado cuenta de la gran importancia que tiene tu relación y la del Equipo Scrum con los Stakeholders.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada.

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies