Práctica de aplicación de Burn Down Charts en el contexto de SAFe y Scrum

En este artículo planeo contar cómo en mi práctica aplicamos el gráfico de quema (Burn Down Chart) en el proceso de trabajo bajo la metodología SAFe

Empezaré, quizás, por lo más interesante. A saber, por el hecho de que el uso de este gráfico en SAFe no debe tener ninguna especificidad respecto al uso de este gráfico en SCRUM. ¿O sí debe?

En nuestro caso, SAFe se diferencia por la presencia de un rol como RTE, a diferencia de SCRUM, donde no existe. Burn Down Chart es una herramienta de seguimiento del volumen de trabajo en el sprint y es necesaria ante todo para el equipo SCRUM, y no para alguien externo, ¿no es así?

Así pues, pasaré de todos modos a cómo usamos Burn Down Chart, pese a todo, y estando todavía dentro del framework SAFe.

Estoy en el rol de Scrum Master y trato de mostrar este gráfico a diario a todo el Dev Team. El medio que utilizo es el chat del equipo, la mención de todo el equipo mediante "@", una captura de pantalla del estado actual del gráfico. La mención de todo el equipo es una herramienta bastante delicada y es importante usarla lo menos posible (pues nosotros, los Scrum Masters, debemos ayudar al equipo a trabajar con comodidad y con la mínima desconcentración posible, ¿no es así?)

En resumen, el equipo ve a diario el estado actual del sprint y es capaz de rastrear los siguientes eventos

• Aparición de trabajo no planificado
• Larga permanencia de tareas en estado no completado
• Asunción excesiva de riesgos
• Comprensión de si el trabajo avanza al ritmo correcto

A continuación trataré de desarrollar cada uno de estos eventos y dar ejemplos de mi práctica.

Aparición de trabajo no planificado

En este gráfico se ve muy bien cómo aparece nuevo trabajo (el segundo martes del sprint de dos semanas).

Caso de la práctica: "El desarrollador, como miembro del equipo scrum que comparte los principios agile, interactúa genial con el Product directamente. El Product le dice que esto hay que implementarlo rapidito, tú mismo lo entiendes, aquí es rápido y los riesgos son mínimos.

El desarrollador es genial, sabe todo sobre agile y sobre la importancia de entregar valor de negocio, va y arrastra al tablero una historia del backlog, el equipo la estimó en 6 sp.

El resto del equipo (excepto el desarrollador y el Product) lo nota en la actualización matutina del gráfico. En el standup el equipo toma la decisión de qué hacer con esta situación. Lo más probable es que la historia se saque del sprint, al Product y al Desarrollador el equipo les da a entender que así no se puede hacer, el product puede poner esta historia en el siguiente sprint si es necesario.

Claro, en el ideal el equipo debería notar la aparición de nuevo trabajo en el standup y sin el gráfico. Pero el gráfico es un buen indicador que reduce al mínimo los riesgos de no notar un cambio tan importante para todo el equipo.

Aquí es importante entender que el escenario podría haber ido de forma distinta según el nivel del equipo. En equipos geniales el Dueño de producto difícilmente habría hecho eso, y si lo hubiera hecho, lo habría argumentado no con que «esto se puede implementar rapidito», sino con que «estimo en un 55% la probabilidad de que si esto se implementa ahora, pueda aumentar nuestra ganancia en un 20% el próximo mes» o alguna otra métrica medible.

Larga permanencia de tareas en estado no completado

Aquí vemos que durante mucho tiempo el trabajo no se completa ni siquiera parcialmente. Esto puede señalar diferentes problemas, enumeraré algunos de ellos

• Mala descomposición de tareas

  Muy a menudo los equipos principiantes hablan de la imposibilidad de descomponer. Todo se quema en el último día, el trabajo no se paraleliza, etc. Por supuesto, con esto es necesario trabajar al Scrum Master y explicar el valor de la descomposición al equipo.

• DOD no formulado de forma óptima

  DOD (Definition of Done) - descripción de los criterios de preparación de una User Story en el sprint. A veces no existen en absoluto o se describen de forma muy abstracta. Esto bien puede ser un problema que, naturalmente, debe ayudar a resolver el Scrum Master

Excesiva inclusión de riesgos

En este caso vemos una situación en la que el equipo incluyó en exceso los riesgos.

Posiblemente, alguna historia fue sobreestimada. Posiblemente, este sea un problema más sistémico y sea necesario aumentar el volumen de trabajo al planificar el sprint. En cualquier caso, esta situación no es correcta. Pues el negocio planificó que se realizarían precisamente las tareas del sprint y precisamente para el final del sprint. Dependiendo de cómo se planificaron las dependencias, aquí lo más probable es que haya que realizar reuniones para ajustar las expectativas.

En mi práctica esto ocurrió cuando se encontró una solución más rápida que la discutida durante la estimación. Discutimos con todo el equipo qué historia podríamos cerrar hasta el final del sprint y en la retrospectiva acordamos que intentaríamos revisar el código durante el grooming. Se descubrió que bastaba con simplemente echar un vistazo al código para entender que la solución era mucho más simple.

Comprensión - si el trabajo avanza al ritmo correcto

Aquí me gustaría llamar la atención sobre las formas gráficamente desafortunadas de mostrar el Burn Down Chart

En la parte superior de la imagen se muestra un ejemplo de una implementación gráfica no muy afortunada por dos razones que expondré a continuación.

• No se nota la inclusión de nuevos SP en el sprint

  Aquí, en el diagrama superior, prácticamente no se nota que se añadió trabajo no planificado. En el inferior esto es más evidente.

• El resto relativo de trabajo no se muestra correctamente

  Según el diagrama superior quedaban aún 3 días de trabajo. En realidad son 2, en el día libre, posiblemente, alguien planea descansar.

Por supuesto, a alguien tales minucias le parecerán insignificantes. Pero hay que entender que cada miembro del equipo solo echará un vistazo de reojo a este diagrama y este debe transmitir el máximo de información útil.