Cómo calcular los valores en el Burn Down Chart en Scrum

Después de la publicación entre amigos del primer artículo sobre el Burn Down Chart, en los comentarios surgió la segunda pregunta que se planteó: "No queda claro cómo se calculan todos estos valores". Por eso, en este artículo intentaré contar cómo calculamos los valores diarios en el Burn Down Chart. Como siempre, estaré encantado de recibir todos los comentarios de los colegas si de repente digo algo incorrecto, pero aun así quiero creer que el tema es suficientemente comprensible para mí.

Recordemos una vez más cómo se ve este diagrama.

En este ejemplo se considera un sprint de 10 días. En él vemos que han pasado 2 días (ya que solo los primeros 2 segmentos están pintados con el gráfico verde).

También vemos el volumen total del sprint - es la línea punteada que muestra que el volumen total del sprint el lunes a las 10:00, el martes a las 10:00 y el miércoles a las 10:00 no cambió y es igual a 17 SP (Story Points).

Según la metodología Scrum, el volumen total de trabajo dentro del sprint no cambia durante el sprint, por eso esta línea se construye a menudo de inmediato para todo el sprint (los 10 días). También ayuda a evaluar cuánto queda por hacer de forma más visual que si terminara en el tercer día en la variante actual.

El burn down real (gráfico verde) muestra el trabajo que queda realmente. Es decir, ahora el equipo ha completado 1 Story Point de los 17 que es necesario completar para finalizar con éxito el sprint. Se considera completada con mayor frecuencia una tarea en estado "Done" (qué es Done para cada equipo, lo determina el propio equipo. Incluso existe un artefacto especial llamado DOD - Definition Of Done - es propio de cada equipo y en él se describe con mucha precisión qué significa que la tarea está hecha y se puede mover al estado "Done". Con mayor frecuencia es "Desplegado en producción", pero puede haber matices. En general, según el gráfico actual entendemos que solo se ha cumplido el DOD en una historia, que el equipo estimó en 1 SP.

El burn down ideal muestra en qué punto debería encontrarse el gráfico del burn down real en caso de un trabajo absolutamente uniforme. Es decir, en este momento deberían haberse completado 3 SP con un trabajo absolutamente uniforme.

Sospecho que puede ser interesante entender qué es un Story Point. En esencia, 1 SP en un equipo y 1 SP en otro equipo pueden ocultar detrás de sí un volumen de trabajo diferente. En nosotros, por ejemplo, hay equipos con la misma cantidad de personas, pero uno tiene una capacidad por sprint de 17 SP y otro de 35 SP. Y esto es normal. La cuestión es que el equipo elige por sí mismo una tarea de referencia respecto a la cual estima todas las tareas en los groomings (nombre obsoleto - es la reunión semanal en la que el PO trae User Stories para estimar, y el equipo las estima mediante el póker de planificación) (En SAFe esto es PBR - Product Backlog Refinement).

Así, podemos tener una User Story de referencia "Yo, en el papel de conductor de automóvil, quiero después de repostar el automóvil tener la posibilidad, si es necesario, de obtener un recibo impreso en papel". Acordar que para nuestro equipo es de 8 SP. Y, cuando el PO cuenta una nueva User Story que debemos estimar, ya la estimamos respecto a la tarea de referencia. En consecuencia, la nueva ya puede ser estimada por el equipo en 5 SP, por ejemplo, etc. todas las historias del backlog reciben sus estimaciones.

La capacidad del equipo se calcula a partir de las estadísticas. En los primeros 1-2 sprints se mide la cantidad de SP que el equipo cierra y se calcula el valor medio, sobre este valor se realiza la planificación (cuando el PO selecciona tareas para el sprint del backlog para una capacidad determinada).

Espero haber descrito con suficiente claridad cómo se obtienen los valores en el Burn Down Chart.