Contenido completo
Respuesta rápida (fragmento destacado):
Las métricas Kanban son cuantificaciones del flujo de trabajo (cantidad, tiempo, variabilidad). Principales: tiempo de entrega (idea → listo), rendimiento (unidades/período), WIP (trabajo en curso), CFD (visualización del flujo), previsibilidad (variación del tiempo de entrega), SLA (unidades entregadas a tiempo). Interpretadas en conjunto, revelan cuellos de botella, eficiencia y capacidad de previsión.
TL;DR (5 puntos):
– Plazo de entrega: tiempo medio desde la idea hasta la finalización (días). Objetivo: reducirlo entre un 30 % y un 50 %.
– Rendimiento: elementos completados por periodo (por semana). Objetivo: aumentar o estabilizar.
– CFD: visualización del flujo en el tiempo. El cuello de botella es donde la banda no avanza.
– Variabilidad: ¿unos días 2 elementos, otros 8? Objetivo: estabilizar.
– Previsibilidad: ¿puedo decir «próxima versión en 30 días»? Objetivo: sí, ±15 %.
Artículo completo
¿Por qué son importantes las métricas?
Situación: El equipo A dice: «Somos rápidos, desarrollamos una función en una semana». El equipo B dice: «Nosotros también, en una semana». Pero:
- Equipo A: algunas funciones en 3 días, otras en 3 semanas (variable)
- Equipo B: cada función en 8-9 días (de forma constante)
Sin métricas, no se nota la diferencia. Con métricas:
- Equipo A: media de 8 días, máximo de 21 días (variable, impredecible)
- Equipo B: media de 8 días, máximo 10 días (estable, predecible)
El equipo B es más fiable (mismo tiempo medio, menos sorpresas).
Las 6 métricas esenciales
1. Plazo de entrega (tiempo total)
Definición: tiempo transcurrido desde el inicio del pedido hasta la entrega al cliente.
Timeline de Feature X:
Jan 1 (ideia)
↓
Jan 5 (entra no backlog)
↓
Jan 12 (aproved, pronto para dev)
↓
Jan 19 (dev termina)
↓
Jan 26 (testes passam)
↓
Feb 2 (em produção)
↓
Feb 3 (cliente vendo)
LEAD TIME: Jan 1 → Feb 3 = 33 dias
Interpretación:
– Plazo de entrega medio: 20 días
– Mín.: 5 días
– Máx.: 45 días
– Percentil 95: 35 días
Acción: «El 95 % de las funciones se lanzan en 35 días. Podemos prometer 35 días con total confianza».
2. Tiempo de ciclo
Definición: tiempo transcurrido desde el inicio del trabajo hasta la entrega.
Mesma Feature X:
Jan 12 (move para "In Progress")
↓
Jan 26 (testes passam, pronto)
CYCLE TIME: Jan 12 → Jan 26 = 14 dias
WAITING TIME: Lead Time - Cycle Time = 33 - 14 = 19 dias
Análisis: 19 días de espera (en la lista de tareas pendientes, tras la aprobación, en la cola de pruebas). Oportunidad: eliminar la espera.
Acción: «Si se reduce el tiempo de espera de 19 a 5 días, el plazo de entrega se reduce a 19 días (frente a 33)».
3. Rendimiento (Salida)
Definición: número de elementos completados por período.
Semana 1: 5 features completadas
Semana 2: 6 features
Semana 3: 4 features (QA em férias)
Semana 4: 7 features
Average Throughput: 5.5 features/semana
Variação: 4-7 (boa estabilidade)
Interpretación:
– Si el rendimiento es estable (5-7), puedo prometer «5-7 funciones por semana»
– Si varía mucho (2-10), es difícil hacer promesas
Acción: «Medir el rendimiento durante 4-8 semanas, detectar variaciones y eliminar las causas».
4. Trabajos en curso (WIP)
Definición: número de tareas en curso simultáneamente.
Monday: 8 items in Dev, 4 in Testing, 2 in Deploy = 14 WIP
Tuesday: 9 items in Dev (alguém iniciou), 3 in Testing = 12 WIP
Wednesday: 7 items in Dev (2 completadas), 5 in Testing = 12 WIP
Ideal WIP for Dev: 8 (based on team size)
Current WIP: 7-9 (ótimo, no target)
Interpretación:
– WIP equilibrado = plazo de entrega previsible
– WIP elevado = plazo de entrega largo, baja calidad
Acción: Límites de trabajo en curso, aplicación automática.
5. Diagrama de flujo acumulativo (CFD)
Gráfico que muestra la evolución de los elementos por columna:
Y-axis: # items
X-axis: time (weeks)
Backlog: cresce (sempre há mais demanda)
Ready: estável (WIP limit)
In Progress: estável (team capacity)
Testing: CRESCENDO (band getting wider = bottleneck!)
Done: lentamente crescendo
Insight: Testing é gargalo. Banda está alargando, items ficando presos.
Acción: «Aumentar la capacidad de pruebas (contratar personal de control de calidad, automatización) o reducir el trabajo en curso de desarrollo».
6. Previsibilidad (varianza del tiempo de entrega)
Definición: ¿en qué medida varía el plazo de entrega? Objetivo: poca variación = previsible.
Feature lead times em 20 realizações:
Distribuição:
10 dias: 1 item (5%)
15 dias: 8 items (40%)
20 dias: 8 items (40%)
25 dias: 2 items (10%)
30 dias: 1 item (5%)
Análise:
Média: 18 dias
Mediana: 18 dias
Desvio padrão: 5 dias
Percentis:
50th (median): 18 dias
85th: 23 dias
95th: 27 dias
Previsibilidade: "95% das features saem em 27 dias. Podemos prometer isso."
Métrica auxiliar: Coeficiente de variación
CV = (Desvio Padrão / Média) × 100
= (5 / 18) × 100 = 28%
Interpretação:
< 20%: excelente previsibilidade
20-40%: bom
40-60%: razoável
> 60%: baixa previsibilidade
Métricas secundarias (opcionales)
Nivel de servicio (cumplimiento del SLA)
Target: 95% de features saem em < 25 dias
Atual: 90% saem em < 25 dias
Performance: 90/95 = 95% SLA compliance (missing target)
Ação: Aumentar capacity ou reduzir escopo
Índice de calidad
Defects after release: 3 bugs em 10 features
Quality rate: (10-3) / 10 = 70%
Target: > 95%
Ação: Increase testing, improve code review
Defectos que se han colado (errores que han llegado a producción)
Regression: 15% de features têm bugs relatados em prod
Trend: Antes 20%, agora 15% (improving)
Cómo interpretar y actuar
Escenario 1: Plazo de entrega en aumento
Semana 1-4: média 15 dias
Semana 5-8: média 18 dias
Semana 9-12: média 22 dias
Trend: aumentando
Causas potenciais:
1. WIP aumentou (mais itens paralelos)
2. Complexidade aumentou (features maiores)
3. Teste queue cresceu (QA bottleneck)
4. Integração ficou complexa
Ação: CFD para ver aonde está o atraso (qual coluna está lenta?)
Escenario 2: Rendimiento inestable
Semana 1: 8 features
Semana 2: 3 features (bug, redirecionou equipe)
Semana 3: 10 features (compensação)
Semana 4: 5 features (falta de stories ready)
Variação: 3-10 (200% spread, ruim)
Ação:
- Spike: investigar semana 2 (qual foi o bug?)
- Planejamento: ter sempre 2+ semanas de stories ready
- Previsão: não prometer 8, prometer 5-10 (range)
Escenario 3: CFD con cuello de botella en fase de prueba
CFD mostra:
- Backlog: crescendo (normal)
- Dev: flat (estável)
- Testing: CRESCENDO (stuck!)
- Done: muito lento
Insight: itens completam Dev, ficam em fila de Testing.
Causas:
1. QA overloaded (1 QA, 5 devs)
2. Testes manuais lentos (não há automation)
3. Testes frágeis (precisam re-rodar)
Ação:
A) Contrate 1 QA (capacidade)
B) Automation framework (velocity)
C) Pair testing (dev + qa, simultâneo)
Para quienes son técnicos:
Cálculos y fórmulas:
Lead Time = Data saída - Data entrada
Cycle Time = Data saída - Data início trabalho
Waiting Time = Lead Time - Cycle Time
Throughput = # items completed / period
Average Throughput = Sum(weekly throughput) / # weeks
WIP (Work in Progress) = count(items not in "Done")
CFD Area = integral of WIP over time
Standard Deviation = sqrt(sum((value - mean)^2) / count)
Coefficient of Variation = std_dev / mean
Percentile = valor em posição (n * percentile / 100)
Ex: 95th percentile em 20 items = item #19
Datos para el seguimiento:
Per item:
- id, title, status, start_date, end_date
- type (feature, bug, techdebt)
- size_estimate
- actual_effort
- completed_date
- defects_found_post_release
Agregações:
- Daily/weekly snapshot de WIP (quantos items em cada coluna)
- Lead time distribution (histogram)
- CFD (cumulative)
- SLA compliance (% on time)
Lista de verificación: Implementación de métricas Kanban
- [ ] Establecer el periodo de recogida: entre 4 y 8 semanas como mínimo (los valores atípicos se estabilizan)
- [ ] Seguimiento: todos los elementos tienen start_date y end_date
- [ ] Herramientas: AgilePlace, Jira o una hoja de cálculo con automatización
- [ ] Cálculos: tiempo de entrega, tiempo de ciclo, rendimiento, variabilidad
- [ ] Visualizaciones: histograma de plazos de entrega, CFD, tendencia del rendimiento
- [ ] Revisiones: semanales (equipo), mensuales (dirección), trimestrales (ejecutivos)
- [ ] Acción: las métricas revelan un problema, el equipo propone una mejora
- [ ] Validación: medir el impacto de la mejora en la próxima recogida
Si solo haces tres cosas…
Realiza un seguimiento del plazo de entrega: media, mínimo, máximo y percentiles. Céntrate en el percentil 95 (lo que puedes prometer).
Representar gráficamente el CFD: visualización clara de dónde está el cuello de botella (¿qué columna se está ensanchando?).
Medir el rendimiento y la variación: ¿cuántos artículos completamos a la semana? ¿Es estable? Si no es así, investigar las causas.
Preguntas frecuentes
P: ¿Qué métrica es la más importante?
R: El tiempo de entrega. Todo gira en torno a eso: un tiempo de entrega más corto = más entregas, mejores previsiones y menos obstáculos.
P: ¿Debo centrarme en el rendimiento o en el tiempo de entrega?
R: En ambos. Un rendimiento sin un tiempo de entrega corto equivale a «hacer mucho, pero lentamente». Un tiempo de entrega sin un rendimiento estable equivale a «rápido, pero impredecible».
P: ¿Cómo le explico los CFD a un ejecutivo?
R: «Si la banda se ensancha = hay un cuello de botella. Si un elemento sale rápidamente de la banda = el flujo es bueno. Si la banda llega lentamente a «Done» = el tiempo de entrega es largo».
P: ¿Cuánto tiempo hay que esperar para ver mejoras en las métricas?
R: De 2 a 4 semanas (cambios rápidos). De 8 a 12 semanas (optimizaciones profundas). Las tendencias se observan en un plazo de 4 a 8 semanas.
Lecturas y referencias
- «La ley de Little» en la teoría de las colas
- «Kanban: Gestión exitosa del cambio» (David Anderson)
- Guía de métricas de Planview AgilePlace
CTA final:
«Las métricas Kanban resultan evidentes cuando alguien las muestra. Hemos implementado un marco de métricas que revela los cuellos de botella, justifica la toma de medidas y demuestra el valor. Taller de 2 horas: analizamos las métricas de tu equipo y ponemos en marcha el seguimiento. Reserva tu plaza ahora».
Lecturas relacionadas
- Límites de trabajo en curso en Kanban
- Kanban empresarial
- Planview AgilePlace
- Paneles de control de cartera
