Cycle Time vs Lead Time
Tiempo que tarda un elemento en completarse desde que se inicia el trabajo.
| Cycle Time | Lead Time | |
|---|---|---|
| Definición | El Cycle Time (Tiempo de Ciclo) es una métrica fundamental en desarrollo de software y metodologías ágiles que mide el tiempo transcurrido desde que un equipo comienza a trabajar activamente en un elemento de trabajo hasta que ese elemento está completamente terminado y listo para entregar. Es importante distinguirlo del Lead Time, que mide el tiempo total desde que el trabajo es solicitado (entra en el backlog) hasta que se entrega. El Cycle Time se enfoca exclusivamente en el tiempo de trabajo activo, excluyendo el tiempo de espera en cola. Por ejemplo, si un ticket se crea el lunes, se empieza a trabajar el miércoles y se completa el viernes, el Lead Time es 5 días pero el Cycle Time es 3 días. El Cycle Time es una de las cuatro métricas clave del framework Kanban (junto con throughput, WIP y work item age) y una de las métricas de flujo más utilizadas en cualquier contexto ágil. Su importancia radica en que refleja directamente la capacidad del equipo para entregar valor de forma eficiente. Daniel Vacanti, en su libro "Actionable Agile Metrics for Predictability", defiende que el Cycle Time es la métrica más importante para los equipos que buscan predictibilidad en sus entregas. | El Lead Time, o tiempo de entrega, es la duración total desde el inicio hasta la finalización de un pedido, a menudo utilizado para medir la eficiencia de las operaciones. |
| Categorías | cycle time, delivery rate, kanban, lead time, métricas, throughput | cycle Time, kanban, lean, métrica |
¿Qué es el Cycle Time?
Tiempo que tarda un elemento en completarse desde que se inicia el trabajo.
Definición
El Cycle Time (Tiempo de Ciclo) es una métrica fundamental en desarrollo de software y metodologías ágiles que mide el tiempo transcurrido desde que un equipo comienza a trabajar activamente en un elemento de trabajo hasta que ese elemento está completamente terminado y listo para entregar.
Es importante distinguirlo del Lead Time, que mide el tiempo total desde que el trabajo es solicitado (entra en el backlog) hasta que se entrega. El Cycle Time se enfoca exclusivamente en el tiempo de trabajo activo, excluyendo el tiempo de espera en cola. Por ejemplo, si un ticket se crea el lunes, se empieza a trabajar el miércoles y se completa el viernes, el Lead Time es 5 días pero el Cycle Time es 3 días.
El Cycle Time es una de las cuatro métricas clave del framework Kanban (junto con throughput, WIP y work item age) y una de las métricas de flujo más utilizadas en cualquier contexto ágil. Su importancia radica en que refleja directamente la capacidad del equipo para entregar valor de forma eficiente.
Daniel Vacanti, en su libro "Actionable Agile Metrics for Predictability", defiende que el Cycle Time es la métrica más importante para los equipos que buscan predictibilidad en sus entregas.
Características
El Cycle Time se distingue por varios aspectos fundamentales:
Fórmula de cálculo
Cycle Time = Fecha de Finalización - Fecha de Inicio + 1
El "+1" se añade para contar los elementos que se completan el mismo día que se inician (evitando un Cycle Time de 0 días).
Diferencias clave con otras métricas
| Métrica | Mide desde | Mide hasta | Incluye espera en cola |
|---|---|---|---|
| Cycle Time | Inicio del trabajo activo | Trabajo completado | No |
| Lead Time | Solicitud del trabajo | Entrega al cliente | Sí |
| Touch Time | Tiempo de trabajo real | Trabajo completado | Solo trabajo activo (sin bloqueos) |
| Throughput | N/A | N/A | Mide cantidad, no tiempo |
Factores que influyen en el Cycle Time
- Work In Progress (WIP): según la Ley de Little, a mayor cantidad de trabajo en progreso simultáneo, mayor será el Cycle Time. Limitar el WIP es la estrategia más efectiva para reducirlo.
- Tamaño de los elementos: elementos más grandes tienen naturalmente un Cycle Time mayor. Dividir el trabajo en piezas más pequeñas reduce el tiempo de ciclo.
- Bloqueos: impedimentos que detienen el trabajo aumentan significativamente el Cycle Time.
- Cuellos de botella: fases del proceso donde se acumula trabajo (por ejemplo, code review o testing) alargan el ciclo completo.
- Cambio de contexto: trabajar en múltiples elementos simultáneamente aumenta el tiempo de cada uno debido al coste cognitivo de la multitarea.
Ley de Little
La Ley de Little establece la relación matemática entre Cycle Time, WIP y Throughput:
Cycle Time = WIP / Throughput
Esto significa que para reducir el Cycle Time, un equipo puede:
- Reducir el WIP (limitar el trabajo en progreso).
- Aumentar el Throughput (mejorar la capacidad de completar trabajo).
Ejemplo práctico
Veamos cómo un equipo de desarrollo utiliza el Cycle Time para mejorar su proceso:
Situación inicial:
El equipo de desarrollo de una plataforma SaaS mide su Cycle Time durante 4 sprints y obtiene estos datos:
Sprint 1: Items completados y su Cycle Time ├── Feature login social ........... 12 días ├── Fix bug carrito ................ 2 días ├── Mejora rendimiento búsqueda .... 8 días ├── Feature notificaciones push .... 15 días └── Actualización dependencias ..... 1 día Cycle Time promedio: 7.6 días Cycle Time mediana: 8 días Percentil 85: 13.5 días
Análisis:
El Scrum Master visualiza los datos en un Scatter Plot (diagrama de dispersión) y observa:
Días │ 15 │ x (notificaciones) 14 │ 13 │ 12 │ x (login social) 11 │ 10 │ 9 │ 8 │ x (rendimiento búsqueda) 7 │ 6 │ 5 │ 4 │ 3 │ 2 │ x (fix bug) 1 │ x (dependencias) └────────────────────────── Elementos completados
El equipo identifica que las features grandes (login social, notificaciones) tienen un Cycle Time desproporcionadamente alto. Analizando más a fondo:
- Notificaciones push (15 días): estuvo bloqueada 5 días esperando la aprobación de un certificado de Apple. Sin el bloqueo, habría sido 10 días.
- Login social (12 días): requería integración con 3 proveedores distintos. Debería haberse dividido en 3 stories separadas.
Acciones de mejora:
- Limitar WIP a 2 items por developer: el equipo tenía developers trabajando en 3-4 cosas simultáneamente.
- Dividir stories grandes: cualquier story estimada en más de 8 story points se divide antes de entrar en el sprint.
- Política de bloqueos: si un item está bloqueado más de 24 horas, se escala inmediatamente al Scrum Master.
Resultado tras 4 sprints de mejora:
Cycle Time promedio: 4.2 días (antes: 7.6) Cycle Time mediana: 3 días (antes: 8) Percentil 85: 6 días (antes: 13.5) Mejora: 45% reducción
¿Por qué es importante?
El Cycle Time es una de las métricas más valiosas para los equipos de desarrollo ágil:
Predictibilidad: conociendo el Cycle Time histórico, un equipo puede hacer predicciones probabilísticas sobre cuándo se completará un elemento de trabajo. Usando el percentil 85, se puede decir con alta confianza: "El 85% de nuestros items se completan en 6 días o menos". Esto es mucho más fiable que las estimaciones basadas en story points.
Indicador de eficiencia del proceso: un Cycle Time alto no necesariamente indica que el equipo trabaje lento; puede indicar problemas sistémicos como exceso de WIP, bloqueos frecuentes, dependencias externas o fases con cuellos de botella. Analizar las causas del Cycle Time alto revela oportunidades de mejora en el proceso.
Satisfacción del cliente: los clientes y stakeholders se benefician directamente de un Cycle Time bajo, ya que significa que sus solicitudes se resuelven más rápido. Reducir el Cycle Time es reducir el tiempo que un cliente espera por una funcionalidad o corrección.
Mejora continua basada en datos: a diferencia de métricas subjetivas, el Cycle Time es objetivo y medible. Los equipos pueden establecer objetivos concretos de mejora, implementar cambios y medir su impacto real en el Cycle Time.
Alineación con Lean: el Cycle Time es una métrica central en el pensamiento Lean, donde el objetivo es maximizar el flujo de valor reduciendo desperdicios (esperas, colas, retrabajo). Optimizar el Cycle Time fuerza al equipo a examinar y mejorar su proceso de punta a punta.
Herramientas para medir Cycle Time
Preguntas frecuentes
¿Cuál es un buen Cycle Time?
No existe un número universal. Depende del contexto, el tipo de trabajo y el equipo. Lo importante es que el Cycle Time sea consistente y tienda a reducirse con el tiempo. Un equipo de desarrollo web podría tener un Cycle Time mediano de 2-5 días para stories, mientras que un equipo de firmware podría tener 10-15 días. La clave es comparar con tu propio historial, no con otros equipos.
¿Debería usar Cycle Time promedio o mediana?
La mediana es generalmente más útil que el promedio porque no se ve distorsionada por valores atípicos. Si un item tarda 30 días por circunstancias excepcionales, el promedio se distorsiona significativamente mientras la mediana permanece estable. Para compromisos, usa el percentil 85 que da un margen de seguridad realista.
¿Cómo afecta el WIP al Cycle Time?
La relación es directa según la Ley de Little: más WIP = mayor Cycle Time. Si un developer trabaja en 3 items simultáneamente, cada uno tardará aproximadamente 3 veces más que si trabajara en uno solo (más el overhead del cambio de contexto). Limitar el WIP es la palanca más poderosa para reducir el Cycle Time.
¿Cycle Time incluye fines de semana y festivos?
Depende de cómo lo configure el equipo. La práctica más común es contar solo días laborables para obtener una medición más precisa del tiempo de trabajo real. Sin embargo, desde la perspectiva del cliente, el tiempo de calendario (incluyendo fines de semana) puede ser más relevante.
¿Puedo usar Cycle Time con Scrum o solo con Kanban?
El Cycle Time se puede usar con cualquier metodología. Aunque es una métrica nativa de Kanban, los equipos Scrum también se benefician enormemente de medirlo. En Scrum, el Cycle Time complementa métricas como la velocidad, proporcionando una visión del flujo individual de cada elemento de trabajo.
¿Cómo se relaciona el Cycle Time con las estimaciones en story points?
Son métricas diferentes y complementarias. Los story points estiman el esfuerzo relativo antes de empezar. El Cycle Time mide el tiempo real después de completar. Con suficientes datos históricos de Cycle Time, algunos equipos eliminan las estimaciones por completo (enfoque #NoEstimates) y usan pronósticos probabilísticos basados en datos históricos de Cycle Time para predecir entregas.
¿Qué es el Lead Time?
Es la duración total desde el inicio hasta la finalización de un pedido.
Definición
El Lead Time, o tiempo de entrega, es la duración total desde el inicio hasta la finalización de un pedido, a menudo utilizado para medir la eficiencia de las operaciones.
Fórmula
Lead Time = Fecha de entrega - Fecha de pedido