Tiempo de ciclo frente a tiempo de entrega: cinco errores de métricas de flujo que los equipos Scrum repiten
Cuando los equipos híbridos y remotos crecieron durante la recuperación de la pandemia, muchos equipos Scrum buscaron mejores señales que la velocidad. Las métricas de flujo, formalizadas en el Kanban Guide for Scrum Teams que scrum.org publica con Daniel Vacanti, eran la respuesta obvia. El problema es que el tiempo de ciclo y el tiempo de entrega son fáciles de definir y sorprendentemente fáciles de medir mal, y una métrica de flujo equivocada es peor que ninguna, porque lleva la autoridad de un número.
Empecemos por las definiciones, porque la mitad de la confusión vive aquí. El tiempo de ciclo es el tiempo transcurrido que un elemento de trabajo pasa en tu flujo, desde el momento en que realmente se empieza a trabajar en él hasta que queda terminado. El tiempo de entrega, en el sentido habitual de prestación de servicio, es el tiempo desde que se solicita o se compromete un elemento hasta que se entrega, así que incluye la espera previa a que alguien lo toque. El tiempo de entrega es lo que siente tu parte interesada. El tiempo de ciclo es lo que tu equipo controla. Confundirlos lleva siempre a la conversación equivocada.
Los errores que engañan a los equipos sin que se note
Medir solo la parte activa. Los equipos suelen arrancar el cronómetro cuando un desarrollador toma un elemento e ignoran los días que pasó en el backlog o en una columna de «listo». El tablero parece sano mientras quien lo pidió espera dos semanas por algo que costó dos días de trabajo. Mide la espera, no solo el esfuerzo.
Tratar los promedios como promesas. El tiempo de ciclo no tiene una distribución normal; tiene una cola larga. Informar un promedio de siete días oculta el elemento que tardó treinta. Usa percentiles en su lugar. Decir «el 85 % de nuestros elementos termina en nueve días o menos» es honesto y pronosticable como nunca lo será un promedio.
Puntos de inicio y fin incoherentes. Si una persona arranca el cronómetro en el refinamiento y otra en el primer commit, tus datos son ruido. Acuerden exactamente qué transición del tablero inicia el tiempo de ciclo y cuál lo termina, escríbanlo y apliquenlo siempre igual.
Dejar que el trabajo en curso se dispare. Por la ley de Little, el tiempo de ciclo promedio crece con la cantidad de trabajo en curso. Los equipos remotos que tomaban más elementos para parecer ocupados entre husos horarios vieron subir sus tiempos de ciclo por motivos ajenos al trabajo en sí. Limita el trabajo en curso y el tiempo de ciclo suele bajar solo.
Manipular el tablero. Dividir un elemento para reiniciar el cronómetro, o deslizar tarjetas hacia atrás para mantener cifras bonitas, destruye el único valor de la métrica. Los datos de flujo son para que el equipo inspeccione y se adapte, no para que un gerente clasifique a las personas. En cuanto se vuelve un objetivo, deja de ser una medición.
Haz que las métricas se ganen su lugar
Las métricas de flujo pertenecen dentro de los eventos Scrum existentes, no en un informe aparte que nadie lee. Lleva un diagrama de dispersión del tiempo de ciclo a la Retrospectiva del Sprint y pregunta qué tenían en común los valores atípicos. Usa los percentiles del tiempo de entrega en la Planificación del Sprint para fijar expectativas realistas con el Product Owner en lugar de adivinar. Durante el Daily Scrum, un gráfico de envejecimiento del trabajo en curso indica a los desarrolladores qué elemento corre el riesgo de convertirse hoy en el próximo atípico, cuando todavía hay tiempo de actuar.
Define los puntos de inicio y fin una vez, por escrito, y nunca los cambies en silencio.
Informa percentiles, no solo promedios, y muestra siempre la distribución completa.
Sigue el tiempo de entrega para la parte interesada y el tiempo de ciclo para el equipo, sin mezclarlos jamás.
Limita el trabajo en curso antes de intentar optimizar cualquier otra cosa.
Usados con honestidad, estos números convierten una frustración vaga en una pregunta concreta y solucionable. El objetivo nunca es un gráfico más bonito; es una espera más corta y previsible para quienes dependen del trabajo.
Si tus equipos de entrega necesitan ayuda para convertir los datos de flujo en decisiones en las que la dirección pueda confiar, la asesoría en gestión de programas y proyectos de XNM puede ayudarte a implementarlos y a leerlos bien.