El otro día me encontré con esta pregunta/comentario en el Grupo de ScrumMaster de Linkedin dónde se preguntaba sobre el análisis de gestión y de gráficos de Burndown.

“Envío a diario Gráficos de Burndown y los altos directivos me han preguntado por qué vemos fluctuaciones, por encima o por debajo de la línea de tendencia ideal.”

Para aquellos que no estén familiarizados con lo que es un Gráfico de Burndown les explico que es una herramienta de control visual que se usa en Scrum para ayudar a los miembros del Equipo a ver si van por el buen camino (o no) para poder entregar el Objetivo del Sprint antes del final del Sprint. El eje X tiene incrementos de tiempo mientras que el eje Y tiene un incremento del trabajo restante estimado. Es una herramienta que ayuda al Equipo a auto-organizarse y que proporciona visibilidad sobre el verdadero estado de su progreso y ayuda al Equipo a inspeccionar-y-adaptar. El ScrumMaster tiene la responsabilidad de crear el Gráfico de Burndown al principio del Sprint, pero el Equipo tiene la responsabilidad de actualizarlo y mantenerlo durante todo el Sprint.

A continuación se muestra un ejemplo típico de lo que es un Gráfico de Burndown. Normalmente los Gráficos de Burndown del Sprint muestran a lo largo de eje X la lista de los días del Sprint. En este ejemplo, estimamos que el trabajo restante está en el eje Y, pero usted puede usar el tiempo o cualquier otra unidad de medida. Todos los datos brutos para un Gráfico de Burndown del Sprint provienen del trabajo que se estima en la Sprint Backlog. Además, yo normalmente añado dos líneas al Burndown del Sprint – una línea continua azul que registra el trabajo restante cada día y una línea discontinua verde que muestra un Burndown ideal. La línea discontinua verde muestra lo que debería ser el progreso del Equipo si completan la misma cantidad de trabajo estimado cada día.

Por favor, tenga en cuenta estas dos cosas sobre la línea ideal en un Gráfico de Burndown del Sprint.

1. En Scrum no es necesario trazar la línea ideal en el Gráfico de Burndown del Sprint. Es solamente una forma interesante para que el Equipo sepa rápidamente si están yendo por el buen camino o no. Cuando la línea continua azul está por encima de la línea discontinua verde, significa que el Equipo no lo está logrando, y cuando la línea azul está por debajo de la línea verde, quiere decir que el Equipo va por el buen camino para poder entregar todo antes del final del Sprint.
2. El Burndown ideal es una fantasía TOTAL y COMPLETA ya que es imposible para el Equipo igualar la tasa del Burndown día tras día. No se debería alentar a un Equipo a que trate de igualar la línea ideal o que mida su eficacia como Equipo basándose en lo cerca que estén de igualar la línea ideal. De nuevo voy a reiterar el primer punto, la línea ideal es solo una conversación interesante sobre si el Equipo va a cumplir con su compromiso (o no) y que acciones se deberían de tomar para asegurarse de que el Equipo alcance su objetivo. Si usted tiene un Equipo que iguala la línea ideal, es porque ellos están falsificando los datos.

En mi experiencia, mandar Gráficos de Burndown a los directivos todos los días es una mala idea y desmerece a Scrum. Cada vez que he visto a una organización hacer esto, he comprobado que terminan debilitando la confianza del Equipo y haciendo que los miembros del Equipo se sientan muy, pero que muy expuestos. Si en estos momentos usted está haciendo esto, le animo a que deje de enviar Gráficos de Burndown a los directivos y a los Stakeholders. Si usted tiene Gráficos de Burndown publicados en algún formato electrónico por todo su edificio o en las wikis, el resultado es el mismo, así que también deje de hacerlo.

Estas son mis razones principales para no publicar un Gráfico de Burndown del Sprint por todas partes dentro de una organización.

1. Esta no es una herramienta de gestión para personas que no pertenecen al Equipo. La gestión diaria de las tareas, la eliminación de retrasos, y el lidiar con el riesgo es responsabilidad del Equipo. El Gráfico de Burndown del Sprint refuerza la responsabilidad del Equipo de entregar un producto que funcione y los anima a inspeccionar-y-adaptar cuando se dan cuentan que van con retraso. Además, las fluctuaciones diarias en un Burndown no tienen ningún significado para cualquiera ajeno al Equipo.
2. Cuando compartimos Gráficos de Burndown del Sprint con personas ajenas al Equipo, es una invitación a la micro gestión y desmerece la auto-organización y el compromiso del Equipo. Si yo le enseño el ejemplo que se muestra arriba a personas ajenas al Equipo, cuando lleguen a la fecha del 16 de marzo empezarán a hacer muchas preguntas – ¿Está yendo el Equipo por buen camino?, ¿Por qué van tan retrasados?, ¿Quién es el responsable de ese retraso?, y mi preferida, ¿Qué podemos hacer para ayudar? Los directivos y los Stakeholders no pueden evitar hacer estas preguntas puesto que todo lo que ven es el gráfico con fluctuaciones y asumen que hay “un problema” y que usted está pidiéndoles ayuda. Estas personas, con todas sus buenas intenciones, piensan que están ayudando haciendo todas estas preguntas pero en realidad solo están distrayendo al Equipo y mostrando que no confían en que el Equipo pueda hacer el trabajo.
3. Los Gráficos de Burndown del Sprint proporcionan un falso sentido de progreso. El progreso en Scrum no se mide por la finalización de tareas según una arbitraria línea ideal, sino por la entrega de un producto valioso al final de cada Sprint, es decir, un producto que sea potencialmente entregable. La única forma en que los directivos y otros Stakeholders pueden determinar el progreso es asistiendo a la Revisión de Sprint de un producto de software que funcione.

Entiendo por qué la gente quiere distribuir Gráficos de Burndown del Sprint y por qué los directivos y los Stakeholders piensan que quieren ver este tipo de datos. Los datos son fáciles de obtener y un Equipo de Scrum los facilita sin problemas. La mayoría de las herramientas electrónicas los producen sin ningún inconveniente.

Sin embargo, si los directivos y los Stakeholders están interesados en este nivel de detalles por parte de un Equipo de Scrum, entonces mi sugerencia es que no están haciendo su verdadero trabajo. En mi opinión, el verdadero trabajo de ellos en Scrum es no saber lo que todo el mundo está haciendo ni estar dándole órdenes a la gente. Su verdadero trabajo es ofrecer liderazgo, proporcionar orientación, establecer direcciones y comunicarse con otras partes ajenas a Scrum. Por desgracia, discutir sobre los Gráficos de Burndown del Sprint y todas sus fluctuaciones solo proporciona la ilusión de control y de que alguien está “dirigiendo” el proyecto o programa.

Así que si quiere mostrarle a la gente algo valioso, entonces muéstrele un Gráfico de Burndown de la Entrega. Esta es una herramienta útil sobre la cual pueden discutir los directivos y los Stakeholders ya que se centra en el valor entregado y en lo que queda por entregar. Este gráfico está organizado de forma muy similar a la del Gráfico de Burndown del Sprint, a excepción de que en este caso los datos brutos proceden de las estimaciones de cada uno de los elementos del Product Backlog. Para más información, por favor vea mi post del 2010 sobre Cómo leer un Gráfico de Burndown de la Entrega y asegúrese de que lee el gran comentario que hizo George Dinwiddie sobre los Gráficos de Burnup.