El objetivo de estos dos posts es establecer el punto de partida sobre un marco de trabajo de métricas para equipos que estén bajo el método Kanban.
La guía viene separada en dos grandes secciones:
- Indicadores: Qué es lo que queremos medir (primer post).
- Gráficas: Donde podremos ver estos indicadores y cómo poder interpretarlos (segundo post).
Indicadores
Introducción
Cuando hablamos de indicadores usualmente se utilizan términos como leading y lagging. ¿Pero qué significan?
Lagging indicators suelen ser “output oriented”, fácil de medir pero difícil de mejorar o influenciar, mientras que los leading indicators suelen ser “input oriented”, difíciles de medir pero fáciles de influenciar.
Pongamos un ejemplo. Imagina que nuestra meta personal es perder peso. Un lagging indicator claro que es fácil de medir. Te subes en la báscula y obtienes la respuesta al momento. Pero … ¿como podemos alcanzar nuestra meta? Para perder peso podemos establecer dos “leading indicators”:
1.- Calorías tomadas
2.- Calorías quemadas
Estos dos indicadores son fáciles de influenciar pero difíciles de medir. Cuando pides en un restaurante la cantidad de calorías no están señalizadas en el menú. Y la mayoría de las personas no tenemos ni idea de cuántas calorías quemamos a lo largo del día.
También te puede ayudar a pensar en la diferenciación en que los leading indicators suelen ser de actividad, y los lagging indicators de resultado.
WIP (Work In Progress)
El número de elementos de trabajo empezados pero no terminados.
Aquí no estamos hablando del WIP Limit (extra: ¿Cómo elegir un buen WIP Limit?) . El WIP Limit es una política que los equipos utilizan para crear un sistema Kanban restringiendo la capacidad máxima de su sistema. La meta del WIP Limit es reducir la cantidad de trabajo en progreso (WIP).
El objetivo de dar transparencia al WIP es mostrar a Stakeholders, e incluso a toda la organización, como la reducción de WIP impacta en las demás métricas.
Una buena manera de observar el WIP es utilizar el Cumulative Flow Diagram (CFD).
Customer Lead Time
La cantidad de tiempo transcurrido desde que un elemento de trabajo es solicitado por un peticionario y un elemento de trabajo está disponible para el usuario.
Este es el tiempo que más interesa al peticionario. El Customer Lead Time está compuesto por cycles time parciales (dentro de cada estado del workflow) y de waiting states entre un paso y otro. ¡Ojo! El Customer Lead Time puede depender de más de un equipo por lo que el workflow total está compuesto por el workflow de diferentes equipos.
Lead Time o System Lead Time
Es el tiempo que transcurre desde que un ítem de trabajo entra en un punto de compromiso hasta que se entrega.
El punto de compromiso suele recibir el nombre de seleccionadas, ready o next.
La gran mayoría de las veces las prioridades de un servicio no están estipuladas por el equipo si no por la organización. Imaginemos que un peticionario realiza una petición “A” con una prioridad 3 sobre 5, siendo 1 la más baja y 5 la más alta. Pero cuando el equipo ejecuta el siguiente replenishment ha llegado otra petición “B” con prioridad máxima 5. Esto deja fuera del sistema a la petición A alargando su Customer Lead Time.
Este es el motivo por el que un equipo se compromete a tener un lead time lo más estable posible y suficientemente bajo y muchas veces no puede comprometerse con un Customer Lead Time. El Lead Time representa el tiempo que el trabajo está en la zona que pertenece al equipo. Mientras que el Customer Lead Time depende de factores que escapan al equipo y puede dispararse por razones externas como un cambios de prioridades.
Esta métrica es un “lagging indicator” de flujo. Está disponible sólo cuando un elemento está ya terminado desde la perspectiva del workflow. Normalmente se utiliza, junto con el Cycle Time, para impulsar trabajo de mejora, así como para poder establecer expectativas internas / externas en cuanto al tiempo de respuesta del equipo en elementos específicos.
La métrica más usada para observar el Lead Time medio aproximado es el Cumulative Flow Diagram.
Lead Time medio aproximado (que no tiene por qué parecerse al lead time de PBIs individuales, por ejemplo, cuando haya cosas muy viejas en el backlog).
Cycle Time
La cantidad de tiempo transcurrido entre que un elemento de trabajo “comienza” desde que pasa un punto de commitment y un elemento de trabajo “termina”. En la siguiente imagen por ejemplo desde que entra en desarrollo hasta que está terminado. También puedes tener cycle time parciales por cada uno de los estados del workflow.
La gráficas más usadas para visualizar y analizar los Cycles Times son:
Throughput
El número de elementos de trabajo “terminado” por unidad de tiempo.
Nótese que la medición del throughput es el número exacto de elementos de trabajo, sin ningún tipo de compensación por el tamaño del mismo. El throughput se puede medir en cualquier paso del workflow y generalmente se utiliza el final del mismo.
El throughput se puede observar utilizando:
Work Item Age
La cantidad de tiempo transcurrido entre cuando se inició el trabajo y la fecha actual.
Work Item Age complementa el Cycle Time. Si el Cycle Time es un lagging indicator relevante sólo para elementos terminados, Work Item Age es un leading indicator solo relevante para los elementos aún en desarrollo. La idea principal de este indicador es proporcionar transparencia sobre qué ítems están fluyendo correctamente y cuales están algo “atascados”, incluso si no están formalmente bloqueados.
El Work Item Age debería ser transparente en el ticket de cada elemento para facilitar buenas decisiones pull. Además, podremos consultarlo en el Aging Work In Progress.
Medir el Work Item Age permite también reducir los riesgos y mejorar la predictibilidad, mejorando la eficiencia global del sistema.
En el siguiente post vemos las gráficas donde analizar estos indicadores. ¡No te lo pierdas! Pulsa aquí para ir directo
El WIP es un leading indicator?