Una buena manera de llevar el seguimiento en Kanban: gráfico acumulativo

Como ya deberías saber o sabes, la métrica más popular en Scrum es la velocidad, que se usa para varias cosas, principalmente, para hacer previsiones (para más información léete ¿Qué es la velocidad en un proyecto software (normalmente ágil o Scrum)? Aclaración de dudas frecuentes o Como estimamos proyectos Scrum o en general ágiles)
En Scrum la velocidad se calcula, normalmente, sumando el número de puntos historia que se estimaron para cada historia de usuario que se ha terminado durante una iteración o sprint. Y de ahí va saliendo una medida (o un intervalo) con la cantidad de cosas que normalmente el equipo termina por cada sprint. Y de ahí hacer predicciones para próximos Sprints.

Pero… ¿Y en Kanban? ¿Qué hay similar en Kanban?

En Kanban (si te suena cero Kanban lee antes esto ¿Qué es el método Kanban para la gestión de proyectos?), ni  la estimación está prescrita, ni el uso de Sprints, ni de diagramas burndown/up…
Pero que no se prescriba una práctica no significa que esté prohibido su uso, de ahí que me suelo encontrar tres combinaciones en Kanban a la hora de buscar estimaciones:
 

1. Tomar de Scrum aquello de la velocidad haciendo uso de puntos historia.
2. Pasar de los puntos historia y medir velocidad en función de ítems terminados en unidad de tiempo (esto conlleva el problema de que los ítems sean todos más o menos del mismo tamaño)
3. Más símple… no estimar. De ahí que quien defiende el #noestimates suele hacer uso de Kanban. Los razonamientos para argumentar el no hacer uso de las estimaciones, o relegar su importancia, son profundas, para no irme por las ramas de objetivo principal del post te recomiendo leer ¿Tiene sentido estimar? Quizá no deberíamos estimar proyectos #NoEstimates explicado.
4. Usar (incluso en combinación con alguno de los anteriores) los diagramas de flujo acumulado (Cumulative Flow Diagram o CFD in inglis).

Diagrama de flujo acumulado en Kanban

En Scrum son típicos los burndow/up, para los seguimientos, etc., pero en Kanban los gráficos no son ni mucho menos obligatorios, por lo que el gráfico de flujo acumulado vuelve a ser algo típico a la vez que opcional.
Aparentemente los diagramas de flujo acumulado en Kanban son algo bastante simple (sacarle su jugo será otra historia). Dos ejes, X e Y, el X es una escala temporal, pongamos días. El Y es el número de “ítems” que hay en cada columna del tablero Kanban cada día. Y te puede llegar a salir un diagrama similar a este que te he pintado en plan rápido:

Simplemente, el diagrama muestra el número e ítems en cada columna del tablero en un momento dado. Con flechas verticales puedes ver el WIP (el trabajo en una parte del proceso, no lo confundir con el límite del WIP) y con flechas horizontales puedes ir viendo los tiempos de entrega, los Lead an Cycle de Kanban.  Y puedes ir viendo dónde están tus cuellos de botella y realizar medias con expectativas de entrega.

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
• Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
• Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024