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

El Product Owner: el desconocido y olvidado

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

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.

Burndown y Burnup para el Scrum Master

Como Scrum Master puedes obtener información muy valiosa analizando estos dos gráficos para entender lo que está ocurriendo en tu equipo.

Por dónde empezar como Product Owner que viene de Tecnología

Estás dando tus primeros pasos como Product Owner, tras haber pasado años diseñando y desarrollando software. Te enfrentas a varios dilemas.

Aprendiendo en un Equipo Scrum

El conocimiento compartido potencia a tu equipo. Aquí descubrirás cómo identificar las áreas de conocimiento y favorecer su aprendizaje continuo

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.

Como empezar como Scrum Master

Acompañar a equipos es una gran responsabilidad pero es muy gratificante. Cada persona y cada equipo tiene unas necesidades diferentes en función de su realidad. Sin embargo, bajo nuestra experiencia, estos consejos pueden servirte para iniciarte como Scrum Master en un equipo.

Mi estrategia de Onboarding como Scrum Master

Me incorporo a un equipo como Scrum Master, ¿¿por dónde empiezo??

Estoy seguro de que esta pregunta ha pasado por la cabeza de más de uno y de una cuando se ha enfrentado al reto de comenzar a trabajar en una nueva empresa o con un nuevo equipo. En este post quiero compartir una estrategia que yo he utilizado y me ha sido útil para abordar el proceso de onboarding.

Lo que te estás perdiendo por hacer «tu» Scrum

¿Qué ocurre si decides utilizar sólo parte de Scrum? Dejar de usar roles, eventos o artefactos tiene sus riesgos.

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.

0 comentarios

Enviar un comentario

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

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

ACEPTAR
Aviso de cookies