Métricas Ágiles: velocidad, lead time y cycle time
Las métricas ágiles permiten al equipo medir su rendimiento y tomar decisiones basadas en datos. Sin embargo, mal utilizadas, pueden convertirse en objetivos perversos que distorsionan el comportamiento del equipo. La clave está en usarlas para aprender, no para juzgar.
¿Por qué medir en Agile?
Medir es fundamental para mejorar. Sin datos, las decisiones se basan en opiniones y corazonadas. Pero medir en Agile requiere un cambio de mentalidad respecto a la medición tradicional.
En los enfoques tradicionales, las métricas se usan para controlar y evaluar. En Agile, las métricas se usan para aprender y mejorar. Esta diferencia parece sutil pero tiene consecuencias enormes. Cuando el equipo sabe que las métricas se usarán para castigarlos, las manipularán. Cuando saben que se usarán para ayudarles a mejorar, las adoptarán como herramienta de crecimiento.
Las métricas ágiles responden a tres preguntas fundamentales:
- ¿Estamos entregando valor? (efectividad)
- ¿Estamos mejorando nuestra forma de trabajar? (eficiencia)
- ¿Estamos saludables como equipo? (sostenibilidad)
Velocidad
La velocidad mide cuántos puntos de historia completa el equipo en un Sprint. Es probablemente la métrica más conocida y también la más mal utilizada.
Cómo calcularla
Suma los puntos de historia de todas las historias completadas en un Sprint. Se considera "completada" una historia que cumple la Definition of Done. Si una historia no está Done, no cuenta para la velocidad, aunque esté "casi terminada".
Para tener una referencia útil, calcula el promedio de los últimos 3 a 5 Sprints. Este promedio se usa durante la Sprint Planning para estimar cuánto trabajo puede abordar el equipo en el próximo Sprint.
Cómo usarla correctamente
- Como estimación de capacidad. Si tu velocidad promedio es 40 puntos y el Sprint dura 2 semanas, puedes comprometerte a unos 35-40 puntos considerando un margen de incertidumbre.
- Como tendencia a largo plazo. Si la velocidad sube o baja de forma consistente durante varios Sprints, algo está cambiando. Investiga por qué.
- Como herramienta de conversación. Durante la Sprint Planning, la velocidad ayuda a tener una conversación realista sobre cuánto trabajo asumir.
La trampa de la velocidad
La velocidad tiene un problema grave: es muy fácil de manipular. Si el equipo sabe que se le evaluará por su velocidad, empezará a inflar estimaciones, a forzar historias incompletas como "Done" o a evitar trabajo técnico necesario porque "no suma puntos".
He visto equipos donde la velocidad "subía" Sprint tras Sprint, pero la calidad del código se desplomaba. Los desarrolladores partían las historias en trozos más pequeños (más puntos por menos trabajo) y evitaban las historias de refactorización porque no daban "puntos visibles".
El principio de Goodhart aplica perfectamente aquí: "Cuando una métrica se convierte en un objetivo, deja de ser una buena métrica." Si conviertes la velocidad en un objetivo obligatorio, el equipo encontrará formas de inflarla que no tienen nada que ver con entregar más valor.
| Uso correcto | Uso incorrecto |
|---|---|
| Referencia para Sprint Planning | Objetivo obligatorio de rendimiento |
| Tendencia a largo plazo para detectar problemas | Comparación entre equipos |
| Conversación sobre capacidad | Evaluación individual de desempeño |
| Ajuste basado en contexto | Meta fija que no se negocia |
Lead Time
El lead time es el tiempo total desde que se solicita una funcionalidad hasta que se entrega al usuario. Incluye todo el tiempo de espera en el backlog, el tiempo de refinamiento, desarrollo, pruebas y despliegue.
Cómo calcularlo
Para calcular el lead time de un elemento, mide desde la fecha en que se añade al backlog hasta la fecha en que se entrega a producción (o al usuario final). La fórmula es simple:
Lead Time = Fecha de entrega - Fecha de solicitud
Cómo usarlo
El lead time es una métrica excelente para gestionar expectativas con los stakeholders. Si el lead time promedio es de 6 semanas, puedes decirle al negocio: "si pides algo hoy, espera tenerlo en unas 6 semanas, aproximadamente".
El lead time también revela problemas de priorización y acumulación de trabajo. Si el lead time está creciendo, puede significar que el equipo está asumiendo más trabajo del que puede entregar (el backlog crece más rápido de lo que se consume).
Ejemplo práctico: Un cliente solicita una integración con Salesforce. La historia se añade al backlog el 1 de marzo. El equipo la empieza a desarrollar el 15 de abril y la entrega el 30 de abril. El lead time es de 60 días, aunque el trabajo real (cycle time) fue solo de 15 días. Los 45 días restantes fueron espera en el backlog.
Cycle Time
El cycle time es el tiempo que el equipo realmente trabaja en un elemento, desde que empieza hasta que termina. Excluye el tiempo de espera en el backlog.
Cómo calcularlo
Mide desde el momento en que el equipo toma el elemento para trabajar en él (por ejemplo, lo mueve a "En Progreso" en el tablero Kanban) hasta que lo da por terminado (lo mueve a "Done").
Cycle Time = Fecha de finalización - Fecha de inicio del trabajo activo
Cómo usarlo
El cycle time revela cuellos de botella en el proceso. Si el cycle time de las historias de frontend es el doble que el de backend, hay un problema de capacidad o habilidades en frontend. Si el cycle Time aumenta cuando hay muchas historias en progreso al mismo tiempo, es señal de que hay demasiado WIP.
Una de las técnicas más potentes es usar un diagrama de dispersión de cycle time (también conocido como scatter plot). Cada punto representa un elemento completado, con su cycle time en el eje Y y la fecha de finalización en el eje X. Esto permite ver si el equipo está mejorando (los puntos bajan con el tiempo) y cuál es el percentil 85 (el cycle time que el equipo puede prometer cumplir el 85 % de las veces).
Cómo mejorar el cycle time
- Limita el WIP (Work in Progress). Cuantas más cosas tenga el equipo en progreso, más lento será cada elemento individual. La ley de Little lo confirma.
- Elimina las esperas. Identifica dónde esperan los elementos: aprobaciones externas, disponibilidad del PO, entornos de pruebas. Cada espera alarga el cycle time.
- Reduce el tamaño de los elementos. Los elementos pequeños se mueven más rápido por el sistema que los grandes. Invierte en refinar historias para que sean más pequeñas.
Otras métricas útiles
| Métrica | Qué mide | Para qué sirve |
|---|---|---|
| Throughput | Número de elementos completados por unidad de tiempo (semana, Sprint) | Predecir capacidad futura, especialmente en Kanban |
| Work in Progress (WIP) | Cantidad de trabajo empezado pero no terminado | Identificar sobrecarga y cuellos de botella |
| Cumulative Flow Diagram (CFD) | Visualiza el flujo de trabajo a lo largo del tiempo | Ver tendencias de WIP, lead time y cycle time de un vistazo |
| Sprint Burndown | Progreso hacia la meta del Sprint día a día | Saber si el equipo va al ritmo esperado |
| Sprint Burnup | Trabajo completado vs alcance total del Sprint | Visualizar cambios de alcance durante el Sprint |
| Net Promoter Score (NPS) | Satisfacción de usuarios o stakeholders | Medir si el valor entregado satisface expectativas |
| Team Happiness | Satisfacción y motivación del equipo | Detectar problemas de salud del equipo antes de que afecten al rendimiento |
Errores comunes al usar métricas ágiles
1. Usar la velocidad como KPI de rendimiento
Es el error más común y más peligroso. Cuando la velocidad se convierte en un objetivo, el equipo deja de usarla para planificar y empieza a manipularla. Las historias se inflan, se evita el trabajo técnico y la calidad se resiente.
2. Comparar métricas entre equipos
Cada equipo tiene su propio contexto, su propia escala de estimación y su propia definición de "Done". Comparar la velocidad del equipo A con la del equipo B no tiene sentido. Lo único que importa es la tendencia de cada equipo respecto a sí mismo.
3. Ignorar el contexto
Una velocidad baja puede ser mala señal... o puede ser que el equipo esté pagando deuda técnica acumulada o aprendiendo una tecnología nueva. Un lead time alto puede deberse a que el PO prioriza mal o a que hay dependencias externas que el equipo no controla. Nunca mires la métrica sin mirar el contexto.
4. Obsesionarse con una sola métrica
Cada métrica cuenta una parte de la historia. La velocidad no dice nada sobre la calidad. El cycle time no dice nada sobre la satisfacción del usuario. Necesitas un conjunto equilibrado de métricas para tener una visión completa.
5. No actuar sobre las métricas
Medir sin actuar es ruido. Si el equipo mide su velocidad pero no ajusta la planificación en base a ella, está perdiendo el tiempo. Las métricas solo valen si generan decisiones y cambios.
Datos del sector
Según el informe "Accelerate: State of DevOps 2023" de Google Cloud, los equipos de alto rendimiento tienen un lead time de menos de un día, mientras que los de bajo rendimiento tienen lead times de entre uno y seis meses. La diferencia no está en las herramientas, está en la cultura de medición y mejora continua.
El estudio también revela que los equipos que miden y visualizan su cycle time reducen el tiempo de entrega en un 30 % en los primeros tres meses. El simple acto de medir, si se hace con transparencia y enfoque en mejora, ya genera resultados.
Paso a paso: implementa métricas en tu equipo
Si estás empezando con métricas ágiles, este es el orden que recomiendo:
- Empieza con el Sprint Burndown. Es la métrica más simple y la que más información da sobre la ejecución del Sprint.
- Añade el cycle time después de 3 Sprints. Una vez que el equipo tenga el hábito de medir, introduce el cycle time para identificar cuellos de botella.
- Calcula el throughput si usas Kanban. En equipos Kanban, el throughput reemplaza a la velocidad como métrica de capacidad.
- Mide la felicidad del equipo desde el día uno. Una encuesta anónima semanal de una sola pregunta ("¿cómo de satisfecho te sientes con tu trabajo esta semana?") puede detectar problemas antes de que se conviertan en crisis.
- Revisa las métricas en la retrospectiva. No las mires para evaluar al equipo; míralas para encontrar oportunidades de mejora.
Mi recomendación personal
La métrica más infravalorada es la felicidad del equipo. He trabajado con equipos que tenían velocidades impresionantes pero estaban quemados. A los tres meses, varios miembros clave pidieron la baja. El coste de reemplazar a un desarrollador senior puede ser de 6 a 9 meses de salario, según datos de la Society for Human Resource Management.
Mi consejo: mide la felicidad del equipo antes de medir cualquier otra cosa. Un equipo feliz es más productivo, comete menos errores y se queda más tiempo en la empresa. La felicidad no es un "nice to have"; es la métrica fundacional. Si el equipo está feliz, las demás métricas suelen mejorar por sí solas.
Conclusión
Las métricas ágiles son herramientas para la mejora, no para la evaluación. Úsalas para identificar patrones, detectar problemas y celebrar avances. Nunca para presionar al equipo o justificar decisiones unilaterales. La mejor métrica es la que el equipo elige para sí mismo y usa activamente para mejorar. El objetivo no es tener las métricas más altas; es tener las métricas que os ayuden a ser mejores cada Sprint.