Gráfico de Antigüedad WIP por Etapa

Vamos a ver. Un tablero Kanban te dice dónde están tus tarjetas. Genial. Pero no te dice cuánto llevan ahí. Y esa información — la dimensión temporal — es la que realmente importa cuando quieres predecir cuándo vas a entregar algo. El gráfico de antigüedad WIP resuelve exactamente eso. Cada punto representa un elemento de trabajó, y su altura te dice cuántos días lleva en esa columna. Cuando ves un punto muy arriba, sabes que algo va mal. Daniel Vacanti lo explica mejor que nadie en su libro: la antigüedad WIP es probablemente la métrica más poderosa que existe para anticipar problemas de flujo antes de que sea demasiado tarde. Me pasó una vez que un equipo tenía un throughput aparentemente estable, pero el gráfico revelaba que tres elementos llevaban más de 20 días en la misma etapa — estaban maquillando las cifras terminando cosas fáciles mientras las difíciles se pudrían. Sin este gráfico, nadie se habría enterado hasta el día de la demo.

¿Te suena la Ley de Little? Es una fórmula elegantísima: tiempo de ciclo promedio = WIP dividido por throughput. Parece sencilla pero las implicaciones son brutales. Si tu equipo completa 10 cosas por semana y tienes 30 en progreso, cada cosa tarda de media 3 semanas. ¿Quieres que tarden menos? Pues reduce el WIP. Así de simple — y así de difícil, porque a la gente le encanta empezar cosas nuevas. Ahora, cuando un elemento muestra alta antigüedad en una etapa, está creando una cola. Reinertsen lo explica con la teoría de colas: cada elemento que se acumula no solo aumenta su propio tiempo de espera, sino el de todos los que vienen detrás. Es como una autopista — al 50% de capacidad fluye bien, al 85% empieza a ir lento, y al 95% se forma un atasco monumental. ¿Y por qué el percentil 85 como umbral de alerta? Porque si un elemento supera esa antigüedad, estadísticamente hablando, tiene muchas papeletas para convertirse en un caso atípico que destroce tu previsibilidad.

Con el tiempo aprendes a leer el gráfico como un médico lee una radiografía. Hay patrones que se repiten. El cuello de botella clásico: muchos puntos altos concentrados en una sola etapa. Típico en Revisión cuando solo hay una persona haciendo code reviews. Solución obvia — más revisores, o pair programming. Luego está el patrón zombie: uno o dos puntos altísimos mientras el resto fluye normal. Esos son elementos que alguien empezó, se bloqueó, y nadie quiere tocar. La verdad es que lo mejor suele ser matarlos o devolverlos al backlog. Después tienes la sobrecarga generalizada — antigüedad alta en todas las etapas, todo va lento. Eso significa que tenéis demasiado WIP, sin más. Reducid los límites y veréis cómo mejora. Y por último, el patrón estacional: cada vez que hay un release o se acercan vacaciones, la antigüedad se dispara. Ese es más fácil de gestionar si lo anticipas — pero primero tienes que verlo, claro.

Vale, ya tienes el gráfico. ¿Y ahora qué? Lo más potente que puedes hacer es cambiar cómo hacéis la daily. En vez de ir de persona en persona — que al final acaba siendo un reporte de estado aburrido — empieza por la derecha del tablero y ve hacia la izquierda. ¿Qué está más cerca de terminarse? ¿Qué lleva más tiempo? Esto es lo que se llama walking the board y, sinceramente, no entiendo por qué no lo hace todo el mundo. Después, establece umbrales con colores. Calcula tus percentiles 50, 75 y 85 de tiempos de ciclo históricos. Verde si estás por debajo del 50, amarillo entré 50 y 85, rojo si superas el 85. Cuando alguien vea rojo, debería soltar lo que esté haciendo y ayudar. En retrospectivas, lleva el gráfico de las últimas dos semanas y comparad con el anterior. ¿Estamos mejorando o empeorando? Y un consejo que me costó aprender: actualiza los datos todos los días. Un gráfico de la semana pasada no sirve para tomar decisiones hoy.