Tiempo de Entrega y Tiempo de Ciclo

Estos términos a menudo se confunden. Aquí están las definiciones precisas:

Tiempo de Entrega: El tiempo total desde que se solicita el trabajo hasta que se entrega.

• El reloj inicia: Cuando el cliente/stakeholder solicita el trabajo
• El reloj se detiene: Cuando el cliente recibe el valor

Tiempo de Ciclo: El tiempo desde que el trabajo comienza hasta que se termina.

• El reloj inicia: Cuando alguien empieza a trabajar en el elemento
• El reloj se detiene: Cuando el trabajo está completo

La relación:

Tiempo de Entrega = Tiempo de Ciclo + Tiempo de Espera (esperando antes de que comience el trabajo)

El tiempo de entrega es lo que le importa a los clientes. El tiempo de ciclo es lo que el equipo controla directamente. Ambos importan.

El tiempo de entrega es la experiencia del cliente. Pidieron algo—¿cuánto tiempo hasta que lo obtuvieron?

Tiempos de entrega cortos significan:

• Retroalimentación más rápida sobre ideas
• Capacidad de responder a cambios del mercado
• Mayor satisfacción del cliente
• Ventaja competitiva

Medir el tiempo de entrega revela:

• El costo total de las colas (a menudo 80%+ del tiempo de entrega es espera)
• Dónde el sistema agrega retraso
• Si las mejoras están funcionando

La mayoría de los equipos subestiman dramáticamente su tiempo de entrega porque solo ven el tiempo de ciclo. "La funcionalidad tomó 3 días construirla" ignora las 3 semanas que estuvo en el backlog y la semana que esperó para el despliegue.

El tiempo de ciclo es la eficiencia interna del equipo. ¿Qué tan rápido podemos completar el trabajo una vez que comenzamos?

Tiempos de ciclo cortos significan:

• Menos trabajo en progreso a la vez
• Ciclos de retroalimentación más rápidos
• Cambio de contexto más fácil
• Entrega más predecible

Medir el tiempo de ciclo revela:

• Cuánta variación existe (¿un poco o mucho?)
• Qué tipos de trabajo toman más tiempo
• Si el equipo se está volviendo más rápido o más lento

La variación importa tanto como el promedio. Un equipo con promedio de 5 días pero rango de 2-20 días es menos predecible que uno con promedio de 7 días y rango de 5-10 días.

Seguimiento manual (inicio simple):

• Registra la fecha en que el trabajo entra a "En Progreso"
• Registra la fecha en que el trabajo llega a "Terminado"
• Calcula la diferencia

Herramientas digitales: La mayoría de las herramientas Kanban rastrean esto automáticamente:

• Jira: Reporte de Tiempo en Estado
• Linear: Analíticas de tiempo de ciclo
• Trello: Con plugins
• Azure DevOps: Gráficas de tiempo de ciclo

Qué rastrear:

• Tiempos de elementos individuales (para tendencias y análisis)
• Percentiles (50, 85, 95) en lugar de solo promedios
• Desglose por tipo de trabajo (¿los bugs son más rápidos que las funcionalidades?)
• Tendencia a lo largo del tiempo (¿mejorando o empeorando?)

Evita:

• Usar solo promedios (ocultan la variación)
• Incluir fines de semana en los cálculos sin pensarlo
• Mezclar diferentes tipos de trabajo en una métrica

Una vez que tengas datos de tiempo de ciclo, úsalos para:

Pronósticos: "85% de los elementos como este se completan en 8 días. Me siento cómodo diciendo que lo tendremos para el próximo viernes."

Identificar problemas: "Este elemento ha estado en progreso por 12 días. Nuestro percentil 85 es de 8 días. Algo está mal—investiguemos."

Validación de mejoras: "El trimestre pasado nuestro tiempo de ciclo mediano fue de 5 días. Este trimestre es de 4 días. Nuestros cambios de proceso están funcionando."

Dimensionamiento correcto: "Las funcionalidades grandes tienen 3 veces la varianza de tiempo de ciclo de las pequeñas. Dividamos el trabajo en piezas más pequeñas."

La perspectiva: El tiempo de ciclo no es solo un reporte—es una herramienta para tomar mejores decisiones en el momento.