Métricas de Flujo que Importan: Más Allá del Velocity
Por qué velocity es una métrica engañosa y qué métricas de flujo realmente predicen la capacidad de entrega y la salud del sistema de trabajo.
Velocity es la métrica ágil más utilizada y probablemente la más dañina. No porque sea incorrecta en su definición, sino porque su uso generalizado ha creado incentivos perversos que degradan la capacidad de entrega que pretende medir.
Cuando un equipo es evaluado por su velocity, aprende rápidamente a inflar estimaciones, dividir historias de forma artificial y priorizar volumen sobre impacto. El número sube, los dashboards se ven bien y la capacidad real de entrega no mejora — o empeora.
El problema fundamental del velocity
Velocity mide la cantidad de trabajo que un equipo completa en un sprint, expresada en story points o unidades similares. Su diseño original, como lo describieron Cohn (2005) y la literatura temprana de Scrum, era servir como herramienta de planificación interna del equipo: una estimación relativa de capacidad que permitía proyectar cuánto trabajo cabía en el siguiente sprint.
El problema surgió cuando las organizaciones convirtieron velocity en una métrica de desempeño: algo que se reporta a stakeholders, se compara entre equipos y se usa para evaluar productividad. Este cambio de contexto transformó una herramienta útil en un incentivo perverso.
Goodhart (1975) lo anticipó: cuando una medida se convierte en objetivo, deja de ser una buena medida. Un equipo cuyo velocity es su KPI optimizará para velocity, no para entrega de valor. Son cosas distintas.
Anderson (2010) propuso una alternativa fundamentada en la teoría de sistemas: medir el flujo de trabajo a través del sistema en lugar de la producción del equipo. Las métricas de flujo no miden cuánto trabaja un equipo, sino cuán efectivamente el sistema de trabajo convierte demanda en valor entregado.
Las cuatro métricas de flujo esenciales
Vacanti (2015) y el framework de métricas de flujo de Kanban University definen cuatro métricas fundamentales que, combinadas, ofrecen una imagen completa de la salud de un sistema de trabajo.
Work in Progress (WIP)
WIP es el número de ítems que están actualmente en proceso — iniciados pero no terminados. Es la métrica más simple y la más subestimada.
La Ley de Little (1961), uno de los resultados más robustos de la teoría de colas, establece que el tiempo promedio que un ítem pasa en el sistema es directamente proporcional al WIP promedio. Esto tiene una implicación contraintuitiva: la forma más rápida de entregar más rápido no es trabajar más rápido, sino trabajar en menos cosas a la vez.
Herramientas para medir WIP:
Jira con sus tableros Kanban muestra WIP por columna de forma nativa. El problema es que la mayoría de las configuraciones no tienen límites de WIP, lo que convierte el tablero en una lista infinita en lugar de un sistema de flujo. La recomendación es configurar límites de WIP explícitos por columna y monitorear las violaciones.
ActionableAgile (de 55 Degrees) es la herramienta especializada más robusta para análisis de flujo. Se conecta a Jira, Azure DevOps, Trello y otros, y genera visualizaciones de flujo que los tableros nativos no ofrecen: diagramas de flujo acumulado, scatterplots de cycle time y análisis de aging.
Kanbanize (ahora Businessmap) ofrece una alternativa para organizaciones que quieren un tablero Kanban con analíticas de flujo integradas desde el diseño, sin depender de herramientas adicionales.
Throughput
Throughput es el número de ítems completados por unidad de tiempo. A diferencia del velocity, throughput mide ítems terminados sin ponderación por estimación. Un ítem es un ítem, independientemente de su tamaño estimado.
Esta simplificación aparente es una fortaleza: elimina el ruido de las estimaciones y mide directamente la capacidad de entrega del sistema. Con suficiente historial (mínimo 15-20 sprints o semanas), el throughput se estabiliza y permite proyecciones probabilísticas más confiables que las basadas en velocity.
Herramienta recomendada: Simulación de Monte Carlo. En lugar de proyectar fechas con un solo número (velocity promedio), la simulación de Monte Carlo usa la distribución histórica del throughput para generar un rango de fechas con niveles de confianza. “Tenemos un 85% de probabilidad de completar estos 30 ítems antes del 15 de marzo” es una proyección mucho más útil que “con nuestro velocity actual, terminaríamos el 8 de marzo”.
Herramientas específicas: ActionableAgile incluye simulación Monte Carlo. Throughput Forecaster (hoja de cálculo de Troy Magennis) es una herramienta gratuita que permite hacer simulaciones sin software adicional. Para equipos con capacidad técnica, las librerías de Python (numpy, scipy) permiten construir simulaciones personalizadas en pocas líneas de código.
Cycle Time
Cycle time es el tiempo que transcurre desde que un ítem entra en proceso hasta que se completa. Es la métrica que más directamente captura la experiencia del cliente: cuánto tiempo pasa entre “lo pedí” y “lo tengo”.
La distribución del cycle time es tan importante como su promedio. Un equipo con un cycle time promedio de 5 días pero con una desviación estándar de 8 días tiene un sistema impredecible: algunos ítems se entregan en un día y otros en tres semanas. La predictibilidad, no la velocidad, es el objetivo operativo.
Visualización clave: Scatterplot de cycle time. Cada punto representa un ítem completado, con la fecha de completación en el eje X y el cycle time en el eje Y. Líneas horizontales marcan los percentiles (50%, 85%, 95%). Este gráfico revela patrones que los promedios esconden: ítems que se “atascan”, períodos de degradación del sistema y el efecto de políticas de WIP.
| Percentil | Significado operativo | Uso para compromisos |
|---|---|---|
| P50 | La mitad de los ítems se completan en este tiempo o menos | Estimaciones internas, planificación de sprint |
| P85 | 85% de los ítems se completan en este tiempo | Compromisos con stakeholders, SLAs internos |
| P95 | Solo el 5% de los ítems excede este tiempo | Peor caso razonable, identificación de outliers |
Work Item Age
Work Item Age mide cuánto tiempo lleva un ítem en proceso sin haberse completado. Es la versión “en vivo” del cycle time: mientras el cycle time se calcula cuando un ítem termina, el aging se calcula mientras el ítem está en progreso.
Esta métrica es la herramienta de gestión proactiva más poderosa del conjunto. Si un ítem tiene un aging que excede el percentil 85 de cycle time del equipo, es una señal clara de que algo está bloqueado o que el ítem es más complejo de lo esperado. Intervenir en ese momento — antes de que el ítem se convierta en un outlier de cycle time — es gestión basada en datos en tiempo real.
Herramienta recomendada: Los tableros de Jira no muestran aging de forma nativa. ActionableAgile lo visualiza claramente. Como alternativa, un script simple en Python que consulte la API de Jira y calcule la edad de cada ítem en progreso puede generar un reporte diario de “ítems en riesgo” que el Scrum Master o facilitador revisa cada mañana.
De métricas a conversaciones
Las métricas de flujo solo generan valor si alimentan conversaciones de mejora. Un equipo que mira un scatterplot de cycle time y no cambia nada está en la misma situación que uno que mira un dashboard decorativo: tiene datos, no tiene decisiones.
Vacanti (2015) propone que las métricas de flujo alimenten tres tipos de conversaciones:
La primera es la conversación de compromiso: cuando un stakeholder pregunta “¿cuándo estará listo?”, la respuesta no es un número sino un rango probabilístico. “Basados en nuestro historial, hay un 85% de probabilidad de que esté listo antes del viernes de la próxima semana.” Esta respuesta es más honesta y más útil que un compromiso puntual que el equipo sabe que no puede garantizar.
La segunda es la conversación de priorización: cuando el WIP excede el límite o cuando un ítem está envejeciendo, la conversación no es “¿quién está trabajando en esto?” sino “¿deberíamos terminar esto antes de empezar algo nuevo?”. Las métricas de flujo hacen visible el costo de la multitarea y la dispersión.
La tercera es la conversación de mejora sistémica: cuando el cycle time muestra una tendencia al alza, la pregunta no es “¿qué hicimos mal?” sino “¿qué cambió en el sistema?”. ¿Aumentó el WIP? ¿Se agregaron dependencias externas? ¿Cambió la composición del equipo? Las métricas de flujo señalan el síntoma; la investigación sistémica revela la causa.
El anti-patrón de la comparación entre equipos
Una advertencia importante: las métricas de flujo no deben usarse para comparar equipos entre sí. Cada equipo opera en un contexto diferente — distinto dominio, distinto nivel de deuda técnica, distintas dependencias — y sus métricas reflejan ese contexto.
La comparación legítima es del equipo consigo mismo a lo largo del tiempo. ¿Nuestro cycle time P85 mejoró respecto al trimestre anterior? ¿Nuestro WIP se estabilizó después de implementar límites? ¿Nuestra predictibilidad (varianza del cycle time) mejoró? Estas preguntas generan aprendizaje. La comparación entre equipos genera competencia y manipulación de métricas — exactamente el mismo problema que tiene velocity.
Métricas como sistema, no como catálogo
Las cuatro métricas de flujo no son cuatro indicadores independientes: son un sistema interconectado. La Ley de Little los relaciona matemáticamente: Cycle Time = WIP / Throughput. Esto significa que no se puede mejorar una sin afectar las otras, y que intentar optimizar una métrica de forma aislada puede degradar el sistema completo.
En nuestros programas de formación en métricas ágiles, enseñamos estas métricas como un sistema de navegación, no como un tablero de puntuación. La pregunta nunca es “¿cuál es nuestro número?” sino “¿qué nos dice el sistema sobre la salud de nuestro flujo de trabajo y qué conversación necesitamos tener?”. La métrica que no genera una conversación de mejora es una métrica que sobra.
Referencias
- Cohn, M. (2005). Agile Estimating and Planning. Prentice Hall.
- Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press.
- Vacanti, D. (2015). Actionable Agile Metrics for Predictability. ActionableAgile Press.
- Little, J. D. C. (1961). A proof for the queuing formula: L = λW. Operations Research, 9(3), 383-387.
- Goodhart, C. A. E. (1975). Problems of monetary management: The U.K. experience. Papers in Monetary Economics.
- Magennis, T. (2017). Forecasting and Simulating Software Development Projects. Focused Objective Press.
- Reinertsen, D. (2009). The Principles of Product Development Flow. Celeritas Publishing.