Métricas de Kanban: lead time, cycle time y WIP
Las métricas en Kanban no se usan para evaluar el rendimiento de las personas, sino para entender cómo fluye el trabajo y dónde hay oportunidades de mejora. Las tres métricas fundamentales son lead time, cycle time y WIP (work in progress). Dominar estas métricas permite al equipo tomar decisiones basadas en datos en lugar de corazonadas. Según el Accelerate State of DevOps 2023 de Google Cloud, los equipos que miden y actúan sobre estas métricas tienen un 45 % más de probabilidades de mejorar su tiempo de entrega mes a mes.
Lead Time: la métrica que importa al cliente
El lead time es el tiempo total desde que se solicita una tarea hasta que se entrega. Incluye todo el tiempo que la tarea pasa en el backlog esperando ser iniciada. Es la métrica que más importa a los stakeholders porque refleja el tiempo que esperan desde que piden algo hasta que lo reciben.
Cómo calcular el lead time
Lead Time = Fecha de entrega - Fecha de solicitud
Por ejemplo, si un cliente solicita una funcionalidad el 1 de marzo y se entrega el 15 de marzo, el lead time es de 14 días. De esos 14 días, la tarea pudo haber estado 8 días en el backlog, 3 días en desarrollo, 2 días en revisión y 1 día en despliegue.
Cómo interpretar el lead time
El lead time es un indicador de la capacidad del sistema completo, no solo del equipo de desarrollo. Un lead time alto puede deberse a:
- Priorización lenta: las tareas pasan demasiado tiempo en el backlog esperando ser priorizadas.
- Cuellos de botella externos: dependencias con otros equipos (QA, seguridad, operaciones).
- WIP demasiado alto: la Ley de Little explica que a más WIP, más lead time.
Ejemplo práctico con datos reales
Imaginemos un equipo de desarrollo que registra su lead time durante un mes:
| Semana | Lead time promedio (días) | Tareas completadas | Observación |
|---|---|---|---|
| Semana 1 | 8,2 | 5 | Límite WIP: 8 |
| Semana 2 | 9,1 | 4 | Aumentó el WIP a 10 |
| Semana 3 | 6,5 | 7 | Redujeron WIP a 6 |
| Semana 4 | 5,8 | 8 | Ajustaron revisión |
El equipo observa que al reducir el WIP de 10 a 6, el lead time bajó un 36 % y el throughput subió un 100 %. Este comportamiento es consistente con la Ley de Little y demuestra que menos WIP produce más velocidad.
Cycle Time: la eficiencia del equipo
El cycle time es el tiempo que el equipo realmente trabaja en una tarea, desde que empieza hasta que termina. Excluye el tiempo de espera en el backlog. Es la métrica que mide la eficiencia del proceso interno del equipo.
Cómo calcular el cycle time
Cycle Time = Fecha de finalización - Fecha de inicio del trabajo activo
Siguiendo el ejemplo anterior, si la tarea empezó a desarrollarse el 9 de marzo y terminó el 15 de marzo, el cycle time es de 6 días (3 de desarrollo + 2 de revisión + 1 de despliegue).
Lead time vs Cycle time: diferencias clave
| Aspecto | Lead Time | Cycle Time |
|---|---|---|
| ¿Qué mide? | Tiempo total desde solicitud a entrega | Tiempo activo de trabajo |
| Incluye espera en backlog | Sí | No |
| Perspectiva | Cliente o stakeholder | Equipo de desarrollo |
| Cómo reducirlo | Mejorando priorización y reduciendo WIP | Eliminando cuellos de botella internos |
| Objetivo típico | < 5 días para equipos de alto rendimiento | < 2 días para equipos de alto rendimiento |
Según el informe Accelerate State of DevOps 2023, los equipos de alto rendimiento (elite) tienen un lead time de menos de 1 día, mientras que los equipos de bajo rendimiento superan los 30 días. Para cycle time, los equipos elite tienen un tiempo de ciclo inferior a 4 horas.
La eficiencia del flujo
Una métrica derivada muy útil es la eficiencia del flujo:
Eficiencia del flujo = Cycle Time / Lead Time
Una eficiencia del 100 % significaría que no hay esperas: el equipo empieza a trabajar en cuanto se solicita la tarea. En la práctica, una eficiencia del 30-50 % se considera buena en equipos de desarrollo. Por debajo del 20 %, hay un problema grave de esperas.
Ejemplo: si el lead time es de 10 días y el cycle time de 3 días, la eficiencia del flujo es del 30 %. Esto significa que el 70 % del tiempo la tarea está esperando (en backlog, esperando revisión, esperando despliegue). Identificar y reducir esas esperas es el camino más rápido para mejorar.
WIP: la métrica que controla todas las demás
El WIP (Work in Progress) es la cantidad de trabajo que el equipo ha empezado pero no ha terminado. Es la métrica más importante porque controla directamente el lead time y el cycle time.
La Ley de Little
La Ley de Little, formulada por John Little en 1961, establece una relación matemática fundamental:
Lead Time = WIP / Throughput
Donde: - Lead Time: tiempo promedio que tarda una tarea en completarse - WIP: número promedio de tareas en progreso - Throughput: número de tareas completadas por unidad de tiempo
Esta ley tiene implicaciones profundas para la gestión de equipos:
- Si duplicas el WIP (empiezas el doble de tareas), duplicas el lead time (tardas el doble en terminarlas).
- Si reduces el WIP a la mitad, reduces el lead time a la mitad.
- El throughput se mantiene constante o incluso mejora al reducir WIP (menos cambios de contexto).
Ejemplo numérico de la Ley de Little
| Escenario | WIP | Throughput (tareas/día) | Lead Time (días) | Estado del equipo |
|---|---|---|---|---|
| Sobrecargado | 12 | 1,5 | 8,0 | Multitarea constante, estrés alto |
| Equilibrado | 6 | 1,5 | 4,0 | Concentración, ritmo sostenible |
| Óptimo | 4 | 1,4 | 2,9 | Alta eficiencia, capacidad de respuesta |
Nótese que al reducir WIP de 12 a 4, el throughput se mantiene prácticamente igual (1,5 vs 1,4 tareas/día), pero el lead time se reduce un 64 %. El equipo entrega al mismo ritmo pero mucho más rápido.
Cumulative Flow Diagram (CFD): la visualización completa
El CFD es un gráfico que muestra el número de tareas en cada etapa a lo largo del tiempo. Es la herramienta visual más poderosa de Kanban porque condensa todas las métricas en una sola imagen.
Cómo leer un CFD
En un CFD, el eje X es el tiempo y el eje Y es el número acumulado de tareas. Cada área de color representa una columna del tablero. La anchura de cada banda en un punto del tiempo muestra el WIP de esa columna.
Qué buscar en un CFD:
| Patrón visual | Significado | Acción recomendada |
|---|---|---|
| Bandas que se separan | El WIP está creciendo | Reducir límites WIP |
| Bandas paralelas | Flujo estable | Monitorear, no cambiar |
| Banda que se estrecha y ensancha | Flujo irregular | Estabilizar el proceso |
| Banda horizontal (sin crecimiento) | Cuello de botella: no se completan tareas | Investigar la columna problemática |
| Pendiente constante | Throughput estable | Buen estado de salud |
Cómo generar un CFD
La mayoría de las herramientas Kanban (Jira, Trello con plugins, LeanKit) generan CFDs automáticamente. Si usas un tablero físico, puedes generar un CFD manualmente registrando el número de tareas en cada columna al final de cada día y trazando las bandas en una hoja de cálculo.
Errores comunes al trabajar con métricas Kanban
1. Medir sin actuar
Muchos equipos recopilan métricas pero no las usan para tomar decisiones. El lead time puede estar subiendo durante semanas sin que nadie ajuste los límites WIP. Las métricas sin acción son solo números.
2. Comparar métricas entre equipos diferentes
El lead time de un equipo de mantenimiento (respuesta rápida) no es comparable con el de un equipo de producto (proyectos largos). Cada equipo tiene su propio contexto y sus propias métricas de referencia. La comparación honesta es contra ti mismo: ¿estamos mejor que el mes pasado?
3. Obsesionarse con una sola métrica
Un equipo que solo mira el lead time puede ignorar que la calidad está bajando. Un equipo que solo mira el throughput puede estar entregando tareas incompletas. Las métricas se leen en conjunto.
4. No registrar la fecha de solicitud
Sin la fecha de solicitud, no puedes calcular el lead time. Parece obvio, pero muchos equipos solo registran cuándo empiezan a trabajar (inicio del cycle time) y pierden la visión del tiempo total de espera del cliente.
5. Usar promedios sin contexto
El lead time promedio puede ser 5 días, pero si la mitad de las tareas se entregan en 1 día y la otra mitad en 10 días, el promedio oculta una alta variabilidad. Usa percentiles (P50, P85, P95) para entender la distribución real.
6. Ignorar la edad de las tareas
Una tarea que lleva 20 días en el tablero es una señal de alerta, aunque el lead time promedio sea de 4 días. La métrica de edad (o aging) identifica tareas estancadas que nadie quiere tocar.
Tabla de métricas derivadas y cómo usarlas
| Métrica | Fórmula | Qué indica | Objetivo saludable |
|---|---|---|---|
| Throughput | Tareas completadas / período | Capacidad de entrega del equipo | Creciente o estable |
| Eficiencia del flujo | Cycle time / Lead time | % de tiempo activo vs espera | > 30 % |
| Edad de la tarea | Días desde que entró al tablero | Tareas estancadas que necesitan atención | < 10 días para el P95 |
| Tasa de entrega a tiempo | Entregas a tiempo / total de entregas | Confiabilidad del equipo | > 85 % |
| Tasa de defectos | Bugs reportados / tareas completadas | Calidad del entregable | < 10 % |
| Predictibilidad | Desviación estándar del lead time | Consistencia del proceso | Baja desviación |
Cómo mejorar usando métricas: guía práctica
-
Si el lead time es alto → reduce el WIP o mejora la priorización. Usa la Ley de Little: si mantienes el mismo throughput pero reduces WIP, el lead time baja automáticamente.
-
Si el cycle time es alto → busca cuellos de botella en el flujo. Analiza el CFD: ¿en qué columna se acumulan las tareas? Esa columna necesita más capacidad o un proceso más eficiente.
-
Si el throughput es bajo → revisa los límites WIP. Un WIP demasiado bajo puede estar infrautilizando al equipo. Un WIP demasiado alto causa multitarea que reduce la productividad real.
-
Si hay tareas estancadas → establece una política para escalarlas. Por ejemplo: "cualquier tarea con más de 10 días en el tablero se discute en la reunión diaria y se asigna un responsable para desbloquearla".
-
Si la eficiencia del flujo es baja → identifica las esperas. Mide cuánto tiempo pasan las tareas en cada columna y ataca las tres esperas más largas.
-
Si la variabilidad es alta → estabiliza el proceso. Los picos y valles en el CFD indican inestabilidad. Trabaja en hacer el flujo más predecible antes de optimizar la velocidad.
Mi recomendación personal sobre métricas
Llevo años ayudando a equipos a implementar métricas Kanban y he visto el mismo error una y otra vez: intentar medir todo desde el día uno. El resultado es confusión, paneles llenos de gráficos que nadie mira y abandono de la práctica.
Mi recomendación es que empieces con solo tres métricas:
- Lead time (promedio semanal)
- Throughput (tareas completadas por semana)
- WIP actual (tareas en progreso hoy)
Estas tres métricas te dan el 80 % de la información que necesitas. Después de 4-6 semanas, cuando el equipo se sienta cómodo con estas tres, añade el CFD y la eficiencia del flujo. Después de 3 meses, incorpora percentiles y edad de tareas.
También quiero destacar un punto importante: las métricas deben ser visibles para todo el equipo, no solo para el líder o el PM. Cuando todos ven los datos, todos participan en la mejora. Un panel compartido en una pantalla grande o una actualización semanal en el canal de Slack del equipo cambia la dinámica de "el jefe nos mide" a "nosotros medimos nuestro progreso".
Por último, recuerda que el objetivo no es tener las mejores métricas, sino mejorar constantemente. Un equipo que honestamente registra que su lead time subió de 4 a 5 días y actúa para corregirlo está haciendo mejor Kanban que un equipo que maquilla sus números para parecer eficiente.
Conclusión
Las métricas de Kanban no son para juzgar, son para aprender. Úsalas en las reuniones de equipo para identificar patrones, celebrar mejoras y ajustar el proceso. La meta no es tener las mejores métricas, sino mejorar constantemente. Como dijo W. Edwards Deming: "Lo que no se mide, no se puede mejorar; lo que no se mejora, se degrada siempre".