Esta métrica no es simplemente un reloj, es una radiografía del flujo de trabajo. Nos dice cuánto tiempo, en la práctica, tarda el equipo en entregar valor real. Esto es vital porque, al contrario de otras formas de estimación, el Cycle Time no se basa en conjeturas, sino en datos empíricos. En definitiva, permite responder con certeza a preguntas clave del negocio como: ¿Cuándo estará listo esto? ¿Cuánto tardamos en resolver peticiones similares?
Indice de contenidos
Los Story Points: de utilidad pedagógica a límite organizacional
Los Story Points surgieron como una herramienta para fomentar conversaciones sobre complejidad (algunos utilizaban también la variable esfuerzo) y facilitar la planificación.
Pero en el desarrollo de software moderno, donde los entornos son altamente inciertos, intentar predecir la complejidad de una historia antes de tocarla es como adivinar si va a llover dentro de tres meses 🤯. Y lo mismo pasa con el valor: es prácticamente imposible saber con exactitud cuál será el impacto real de una funcionalidad antes de desplegarla y ver qué hacen los usuarios con ella.
En este contexto, los puntos de historia se han convertido en una herramienta imprecisa y, a veces, contraproducente. Son subjetivos, desconectados del lenguaje del negocio, que piensa en plazos y resultados, no en esfuerzo estimado ni en complejidad. Esto solo hace que los equipos se presten a juegos de métrica: inflar puntos, redefinir criterios de aceptación o forzar incrementos de su Velocity cuando los equipos sienten presión externa.
Como también ha señalado Ron Jeffries, uno de los creadores del concepto, los Story Points se han convertido con el tiempo en algo muy distinto de lo que fueron pensados originalmente. Incluso él mismo ha cuestionado si deberíamos seguir usándolos.
El Cycle Time como espejo de la realidad
El cycle time se apoya en hechos, no en opiniones. Cada historia completada tiene un tiempo medible entre inicio y fin en el WorkFlow. Esa transparencia ayuda a:
- Ofrecer previsiones realistas basadas en el histórico de datos del equipo, por ejemplo, usando percentiles en scatterplots que se pueden obtener del Cycle Time Scatterplot.
- Detectar cuellos de botella reales, no supuestos.
- Promover conversaciones de mejora del sistema, no de justificación de estimaciones.
Por ejemplo, un Cycle Time Scatterplot muestra cada historia como un punto en el tiempo, y permite identificar visualmente si hay variabilidad alta (3 patrones en Cycle Time Scatterplot), cuellos de botella persistentes o historias atípicas. En vez de preguntarse ¿por qué fallan las estimaciones? los equipos pueden reflexionar: ¿Qué está perjudicando o frenando nuestro flujo?
En un entorno complejo, el tiempo de ciclo nos permite ver lo que está ocurriendo realmente. Y si bien eso puede resultar incómodo (no nos gusta lo que el Cycle Time nos muestra), es la base para cualquier mejora sostenible.
En este gráfico (investigando… 🔍 ), tomado de un equipo real usando Actionable Agile Metrics, se ha filtrado por historias estimadas en 2 puntos. Como puede verse, los tiempos de entrega varían desde unos pocos días hasta más de 30, sin ninguna correlación aparente con el valor estimado. Este patrón se repite también en historias estimadas en 3, 5 u 8 puntos.
Es decir, una misma estimación puede tener múltiples resultados en tiempo real, lo que refuerza la idea de que las estimaciones por puntos no reflejan la realidad del flujo.
El peligro de manipular la realidad
⚠️ OJO ⚠️: No todo uso del Cycle Time es saludable. Una mala práctica común es excluir los tiempos de espera del cálculo, bajo la excusa de que “no dependen de nosotros”. Es como medir solo el tiempo de vuelo y no el que pasamos esperando en el aeropuerto: el cliente sigue llegando tarde igual.
Excluir tiempos de espera, QA, aprobaciones o días no laborables puede parecer una forma rápida de mostrar una mejora, pero en realidad es maquillar la métrica. No nos ayuda a entregar más rápido, ni mejora el sistema. Si una historia estuvo 7 días esperando validación, ese tiempo forma parte de lo que el cliente vive. Y por tanto, debe contarse.
El verdadero valor del Cycle Time está en reflejar el flujo completo, no solo la parte que nos conviene mostrar. Como toda métrica, su utilidad depende del uso que le damos y del contexto en el que se interpreta.
Además, si lo que buscamos es mejorar, conviene recordar que rara vez podemos reducir significativamente el touch time (el tiempo efectivo de trabajo= tiempo total – tiempos de espera o bloqueos). Sin embargo, en la mayoría de los casos, sí es posible mejorar drásticamente el Cycle Time actuando sobre los tiempos de espera, bloqueos, aprobaciones y transiciones.
Comparando enfoques: estimar vs. observar
| Característica | Story Points | Cycle Time |
| Naturaleza | Subjetiva, relativa | Empírica, observable |
| Propósito | Estimar esfuerzo y complejidad | Medir tiempo real de entrega |
| Riesgo común | Pensamiento mágico, inflación | Excluir esperas |
| Valor para el negocio | Indirecto, requiere traducción | Directo, en días reales |
| Estímulo para mejorar | Enfocado en estimar mejor | Enfocado en mejorar el flujoEnfocado en mejorar el flujo |
Este contraste muestra por qué muchos equipos están migrando hacia métricas de flujo: son más honestas, accionables y comprensibles para todos los niveles de la organización.
Historias reales y ejemplos
Pensemos en un equipo que usaba story points para estimar sus historias. Su Velocity promedio (en futuros post se hablará del problema de las medias y soluciones avanzadas para ello) era de 30 puntos por sprint, pero muchas veces no cumplían los compromisos ( peligro de usar planificado vs completado como métrica). Cuando analizaron su cycle time descubrieron que, aunque algunas historias se completaban en 2 días, otras similares tardaban hasta 12 días, por bloqueos en aprobaciones de diseño o validaciones QA. El problema no estaba en estimar mejor, sino en reducir la variabilidad del flujo y esto pasa por descongestionar el sistema.
Al cambiar el foco hacia el Cycle Time:
- Empezaron a controlar el trabajo en curso.
- Tuvieron conversaciones más productivas sobre cuellos de botella.
- Dejar de estimar les ahorró tiempo de planificación, existen herramientas como Actionable Agile Metrics que te puede ofrecer la previsión del Sprint o de un periodo determinado en 5 segundos.
- Mejoraron la previsión de fechas con datos reales.
Este tipo de transiciones se está dando cada vez con más frecuencia, impulsadas por la necesidad de responder rápido en mercados inciertos.
Transición saludable: de estimar a observar
Hacer el cambio de puntos de historia a Cycle tTme implica:
- Observar la realidad: Medir cuánto tiempo están tardando las historias en completarse en la práctica.
- Visualizar patrones: Usar scatterplots y percentiles para ver la variabilidad y las tendencias.
- Conversar sobre flujos, no sobre esfuerzo: Cambiar las conversaciones de ¿Cuántos puntos vale esto? a ¿Qué impide que esta historia fluya más rápido?
- Formar al equipo: Entender que mejorar el Flow es mejorar la entrega de valor.
- Usar SLE’s (Service Level Expectations): Por ejemplo, el 85% de nuestras historias se completan en 8 días o menos.
- Revisar los WorkFlows: Alinear los tableros visuales para reflejar el flujo real.
Los Story Points pueden haber tenido sentido como herramienta de aprendizaje, pero ya no están a la altura de los desafíos actuales. En cambio, el Cycle Time ofrece una guía empírica para tomar decisiones, mejorar el sistema y responder al negocio con hechos, no suposiciones.
En entornos complejos, donde ni el valor ni la complejidad pueden predecirse con certeza, medir y observar lo que realmente ocurre es mucho más efectivo que intentar adivinar. Como señalan voces como Johanna Rothman y Daniel Vacanti, el futuro de la agilidad pasa por métricas de flujo reales, no por puntos imaginarios. Apostar por el Cycle Time es dejar de adivinar y empezar a comprender.
