

Class Registration
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.
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.
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.