Métricas Kanban para hacer pronósticos: WIP, Cycle Time y Throughput

Todo el mundo está a tope, pero no estamos entregando nada.

MAURICIO BOTERO
Software Engineer

Hace un tiempo trabajé en un equipo de veinte personas que no llegaba a los objetivos de ningún sprint y no sabía explicar el motivo. El tablero Kanban llevaba meses registrando cómo avanzaba el trabajo, pero nadie miraba esos datos para decidir nada. Ahí empezó mi interés por utilizar las métricas Kanban para elaborar pronósticos, dejar de discutir cuánto trabajo debería completar el equipo y empezar a analizar cuánto podía completar realmente, utilizando datos históricos y expresando los resultados en términos de probabilidad.

Bastan tres métricas: WIP, cycle time y throughput. Con ellas y el histórico que tu tablero ya guarda, puedes responder con un porcentaje de probabilidad a cuántos elementos entran en un sprint, cuándo se cerrará un backlog de 100 tickets y qué está tardando más de lo normal.

El día que los puntos de historia dejaron de servir

La planificación de aquel equipo consumía un día completo. Veinte personas sumando y restando horas, estimando cuánto tiempo podía dedicar cada uno, asignando todos los tickets del sprint en esa misma sesión. Al día siguiente alguien se ponía enfermo y el plan ya no servía para nada.

El problema de fondo no era la duración de la reunión, sino que convertíamos puntos de historia en horas. Los puntos se concibieron para comparar el tamaño relativo de las historias, no para decidir cuándo algo estará listo. Si lo que quieres es una previsión en horas, trabaja directamente en horas y asume lo que eso implica.

Cuando me puse a revisar los datos, la correlación que todos daban por supuesta no aparecía:

• Elementos estimados en 2 puntos que tardaban dos o tres semanas en cerrarse.
• Elementos con muchos más puntos que se terminaban en uno o dos días.

Sin correlación entre la estimación y el tiempo real de finalización, tomar decisiones sobre esa métrica significa comprometerse con cosas que probablemente no se van a cumplir. Y es la persona que desarrolla la que sufre las consecuencias, ya que sobre ella cae la presión de sostener una fecha que nunca tuvo base.

Había un segundo síntoma, más sutil: la sensación de que todo el mundo estaba ocupado. Ocupación y entrega no son lo mismo. Nadie sabe si algo aporta valor hasta que se termina y se puede validar, así que un equipo al máximo de carga y con nada cerrado no está entregando: está acumulando inventario.

Conviene separar una cosa: una estimación de alto nivel es útil, tratarla como un compromiso no. En desarrollo, descubres el problema real cuando empiezas a trabajarlo. Medir el proceso tal como ocurre, no como nos gustaría que ocurriera, es lo que permite decidir mejor.

Las tres métricas que sí describen el proceso

Un tablero Kanban (da igual si trabajas con Scrum, con otro marco ágil o sin ninguno) ya registra lo que necesitas. Con Jira, Trello o cualquier gestor de tickets tienes disponibles las métricas de flujo que la Kanban Guide considera obligatorias:

• WIP (Work In Progress): el número de elementos en curso, es decir, empezados y no terminados. Indica multitarea, colas y congestión. La regla práctica: más WIP implica más esperas y más esperas, a su vez, más tiempo hasta terminar. El WIP es el inventario del sistema: si crece con el mismo equipo, el tiempo de entrega crece con él.

• Cycle Time: el tiempo que tarda un elemento desde el punto del proceso que decides monitorizar hasta que queda cerrado. La clave está en leerlo por percentiles (p50, p85, p95) y no por promedio. Los outliers (los pocos elementos que se desvían mucho del resto) distorsionan la media lo suficiente como para llevarte a decisiones equivocadas, mientras que un percentil da una conversación de probabilidad: «hay un 70% de opciones de que esto se cierre en 40 días o menos».

• Throughput: la cantidad de elementos terminados por unidad de tiempo, sea semanal o diaria. Es la capacidad real de salida del sistema y su histórico es la materia prima de cualquier pronóstico.

Las tres se relacionan a través de la ley que Little formuló para sistemas de colas y que se aplica igual a un tablero de trabajo:

WIP = Throughput × Cycle Time

Cycle Time = WIP / Throughput
Throughput = WIP / Cycle Time

La lectura práctica: si mantienes la salida y subes el inventario, el tiempo de entrega sube. Y para bajar el cycle time solo hay dos palancas, limitar el trabajo en curso o mejorar la capacidad efectiva del proceso. Es una ley de promedios: funciona bien en sistemas estables y peor cuando el proceso está descontrolado.

Usar métricas Kanban para hacer pronósticos en un proyecto real

En el proyecto del cliente que llevo ahora tenemos estas métricas conectadas al tablero y el orden en que las miro es siempre el mismo.

1. El diagrama de flujo acumulativo muestra el WIP de cada día y cómo van pasando los elementos por cada etapa. Un cuello de botella se ve como una franja más gruesa que las demás y el caso más habitual es desarrollo entregando más rápido de lo que calidad puede probar. Si no limitas lo que le llega al equipo de pruebas, cuando calidad encuentre algo que corregir quien lo desarrolló ya estará en otra tarea: tendrá que parar y reconstruir un contexto olvidado.
2. El throughput diario deja ver el ritmo de entrega. En las primeras semanas la gráfica estaba plana: el equipo a tope y nada saliendo, porque las historias no permitían validar ni entregar nada. Al ajustar cómo se creaban los tickets, empezó a moverse.
3. La distribución de cycle time es el pasado: los elementos ya cerrados. Sirve para responder con datos a «¿cuánto tarda esto normalmente?» y ver si los tiempos están donde deberían.

Con ese histórico ya se pueden lanzar simulaciones y ahí cambia la conversación. Dando la fecha de inicio del sprint y su duración, la simulación devuelve algo así: con un 85% de probabilidad el equipo cierra 6 elementos o más. Con esa cifra y las prioridades del product owner, la planificación pasa de un día entero a unos minutos: se arranca por los seis prioritarios y el resto se reparte a medida que la gente termina.

El mismo cálculo sirve para el medio plazo. Con 100 elementos en el backlog y empezando hoy, la simulación nos dio un 85% de probabilidad de tardar 166 días: fecha estimada, el 21 de junio. Eso no cierra la conversación, la abre: si el negocio lo necesita antes, toca recortar alcance con meses de margen en lugar de descubrirlo en la última semana.

Gestión de riesgos: la única gráfica que mira el presente

Todo lo anterior describe lo que ya pasó, pero actualmente la gráfica que uso a diario es otra: la del envejecimiento del trabajo en curso, que muestra los elementos en progreso y cuántos días llevan, agrupados en franjas por antigüedad. Cuando un ticket cruza de una franja a la siguiente, aumenta la probabilidad de que se alargue y eso la convierte en un sistema de alertas: más de 20 días ya es señal de riesgo.

Poner eso delante del equipo no señala a nadie: cuando estás metido en el desarrollo, pierdes la visión completa del tablero. Las decisiones se toman en grupo y casi siempre son de tres tipos:

• Pedir apoyo, cuando alguien lleva días atascado.
• Desglosar la historia, cuando es más grande de lo que parecía.
• Etiquetar el bloqueo, cuando depende de algo externo al equipo.

Ese último punto esconde un detalle de diseño que marcó la diferencia: la historia bloqueada se queda en su columna con una etiqueta, así conservamos la visibilidad de dónde está bloqueada (en desarrollo, en pruebas…) y cuánto tiempo lleva así. El panel permite además fijar alertas: más de cinco días en el mismo estado, por ejemplo.

Presenté todo esto en una sesión de Knowledge Sharing interna y el turno de preguntas dejó un matiz y una duda. El matiz lo puso David Rueda, compañero e ingeniero en Orbitant: coincidía en que sirve para casi cualquier proyecto, con la salvedad de que en los que van holgados de fechas puede sobrar.

Es aplicable prácticamente a todos los proyectos. En los que son un poco más laxos con las fechas, a lo mejor lo vería como un overkill

DAVID RUEDA
Software Engineer

La duda la planteó otro compañero, Lucas Jin: si un ticket tarda cuatro horas y otro una semana, ¿qué está midiendo la métrica? Mi respuesta es que pretender que todos tengan el mismo tamaño es imposible, pero sí puedes fijar unos criterios de entrada al backlog:

1. Que se pueda validar en cuanto se termine.
2. Que sea lo más independiente posible.
3. Que tenga un tamaño razonable para cerrarse en pocos días.

El ruido que queda lo absorben los percentiles.

El siguiente paso es llevar estas métricas a otros proyectos y comprobar si aportan valor en cada contexto: el objetivo no es estandarizar un tablero, sino tener la caja de herramientas completa y coger la que encaje con el problema. Si en tu equipo la planificación sigue siendo una negociación de horas, empieza por lo más barato: mira el cycle time de los últimos tres meses por percentiles y compáralo con lo que prometéis. Esa diferencia es el tamaño real del problema.

Preguntas frecuentes

¿Necesito abandonar Scrum para usar métricas de flujo?
No. Estas métricas salen del tablero, no del marco de trabajo. Puedes usarlas con sprints, sin ellos o con cualquier proceso en el que los elementos avancen por estados definidos. En un contexto de Scrum sustituyen la estimación por puntos como base para decidir el alcance del sprint.

¿Cuántos datos históricos hacen falta para que un pronóstico sea fiable?
Lo que importa no es solo el volumen, sino la estabilidad. Si el throughput de las últimas semanas es errático porque el proceso o el equipo están cambiando, la simulación heredará ese ruido. Merece la pena estabilizar el flujo antes de tomar decisiones de negocio sobre las proyecciones.

¿Qué hago si el cycle time de mi equipo sale altísimo?
Es una señal de diagnóstico, no un veredicto. Revisa el diagrama de flujo acumulativo para localizar en qué etapa se acumula el trabajo, mira si el WIP está por encima de lo que el equipo puede sostener y comprueba si los tickets están planteados para poder cerrarse de forma independiente.