Saltar a contenido

Gestión de Flujo Kanban: WIP Limits, Aging y Tablero Único#

La gestión efectiva de un flujo de trabajo Kanban se apoya en dos prácticas complementarias: limitar lo que entra (WIP Limits) y monitorear lo que envejece (WIP Aging). A esto se suma un principio estructural: preferir un tablero único por equipo en lugar de fragmentar el trabajo en múltiples tableros por proyecto. Juntas, estas tres prácticas permiten al equipo dejar de empezar y empezar a terminar.

Ley de Little#

La Ley de Little establece la relación fundamental entre las tres métricas de flujo:

1
Cycle Time = WIP / Throughput

Donde:

  • Cycle Time: tiempo promedio que una tarea tarda en completarse desde que se inicia.
  • WIP (Work in Progress): cantidad de trabajo en progreso en un momento dado.
  • Throughput: tasa a la que se completa el trabajo (ítems por período).

Implicaciones prácticas#

Para reducir los tiempos de entrega, hay dos caminos:

  1. Aumentar el Throughput — normalmente requiere inversión (más personas, mejores herramientas) y tiene un costo.
  2. Reducir el WIP — mucho más conveniente: solo requiere la disciplina de no empezar trabajo nuevo hasta terminar lo existente.

Por eso limitar el WIP es la palanca más accesible y efectiva para mejorar la velocidad de un flujo de trabajo.

WIP Limits#

Limitar el WIP es la práctica central de Kanban. El objetivo es alinear la demanda con la capacidad real del equipo, evitando la sobrecarga que genera multitasking, context switching y deuda de flujo.

Cómo establecer límites iniciales#

No existe una fórmula universal. La estrategia recomendada es hacer una estimación inicial y ajustar iterativamente:

  1. Que el equipo decida: son quienes conocen su capacidad. Preguntar a cada persona: "¿Cuántas cosas puedes hacer al mismo tiempo y aún estar en tu lugar feliz?"
  2. Considerar todas las perspectivas: si una persona trabaja en múltiples columnas (ej. desarrollo y revisión), dividir su WIP entre ellas. Si su sweet spot es 2 ítems, asignar WIP de 1 a cada columna.
  3. Reducir hasta aumentar el flujo: bajar los límites al punto donde el flujo mejora y la calidad aumenta, sin sacrificar motivación.

Cómo introducir sin resistencia#

El error común es imponer los límites sin preparación. Si el equipo tiene dependencias externas o no hay claridad en los Criterios de Aceptación, los límites pueden empeorar las cosas.

Estrategia efectiva: antes de hablar de límites, acordar una política explícita de selección de trabajo:

Una vez que terminas una tarea, antes de tomar algo nuevo, recorre el tablero de derecha a izquierda. Busca ítems sin asignar, cosas esperando revisión, feedback por implementar. Solo empieza trabajo nuevo si literalmente no hay nada que puedas hacer para ayudar a que el trabajo existente avance.

Si el equipo maneja bien este enfoque, avanzar gradualmente:

  1. WIP limits personales → 2. WIP limits por columna → 3. WIP limit del sistema completo

Un cambio a la vez, midiendo el impacto. Si funciona, avanzar. Si no, revertir, evaluar qué falló y resolverlo.

Ajuste de límites#

Los límites pueden ajustarse, pero no a diario (pierden valor). Solo cuando las circunstancias cambian:

  • Un miembro del equipo se va de vacaciones por un período extenso.
  • Se incorpora o se pierde un miembro del equipo.

Nunca aumentar los límites solo porque hay alta demanda. Según la Ley de Little, eso solo aumentará los cycle times. La demanda debe alinearse con la capacidad, no al revés.

Visualización del impacto#

Para verificar si los límites están funcionando, se usa un Cycle Time Scatterplot organizado por fecha de inicio (no de finalización). La fecha de finalización oculta el efecto inmediato porque el trabajo envejecido que ya estaba en progreso sigue apareciendo con cycle times altos. La fecha de inicio revela que las tareas comenzadas después de implementar los límites tienen cycle times mucho más predecibles.

WIP Aging y el Aging Chart#

WIP Aging es el tiempo que un ítem de trabajo ya ha pasado en el flujo hasta el momento presente. Es la contraparte en-progreso del Cycle Time: mientras el cycle time mide tareas completadas, el WIP Aging mide tareas que aún están en proceso.

Es la métrica más importante para equipos ágiles porque es la única que los equipos pueden influenciar directamente. Si se gana control sobre el WIP Aging, las demás métricas mejoran como consecuencia.

El Aging Chart#

El Aging Chart es la herramienta de visualización para monitorear el WIP Aging. Tiene el mismo formato que un tablero Kanban, con cada columna representando un estado del flujo, y muestra cuántos días lleva cada tarea en progreso.

Zonas de salud#

Las zonas coloreadas representan percentiles del tiempo que las tareas completadas han pasado históricamente en cada estado:

Zona Percentil Significado
Verde oscuro 30% El 30% más rápido de tareas históricas pasó en este tiempo
Verde claro 50% Mediana — la mitad de tareas históricas
Amarillo 70% Disparador de conversación
Naranja 85% Señal de atención — más lento que el 85% del historial
Rojo claro 95% Crítico — más lento que el 95% del historial

Si un ítem está por encima de la zona roja clara, está tomando más tiempo que el 95% de las tareas previamente completadas en ese estado.

Uso en daily standups#

Incorporar el Aging Chart en las reuniones diarias al menos dos veces por semana. El foco debe estar en las tareas en zonas naranja y roja. La conversación no es sobre personas sino sobre el sistema:

"¿Hay algo que nosotros, como equipo, podamos hacer para que esta tarea avance?"

Acciones concretas:

  1. Identificar qué está causando el estancamiento.
  2. Definir un plan de acción conciso (máximo 3 ítems).
  3. Asignar un responsable para cada acción.
  4. Al día siguiente, empezar la reunión dando seguimiento al plan.

Este enfoque proactivo previene cuellos de botella y mantiene los cycle times consistentes.

Aging en las daily meetings de 23people

El concepto de Aging ya está incorporado en nuestra Guía de Reuniones Diarias Kanban, donde se priorizan los ítems por su tiempo en el flujo. El Aging Chart añade la capa de visualización por percentiles para tomar decisiones basadas en datos históricos.

Gestión de Múltiples Proyectos en un Tablero Único#

Un principio fundamental de Kanban es que los tableros se crean por equipo, no por proyecto. Cuando el trabajo de un equipo se distribuye en múltiples tableros (uno por proyecto), se generan tres problemas críticos:

  1. Prioridades múltiples: un mismo miembro del equipo termina con múltiples prioridades #1, una por cada tablero.
  2. Capacidad invisible: como responsable del equipo, es imposible evaluar la capacidad real si los datos están fragmentados.
  3. Forecasting imposible: sin una visión holística del trabajo, no se puede predecir cuándo se entregarán los proyectos.

Priorización con FIFO#

Cuando todas las tareas de todos los proyectos están en el mismo tablero, la priorización es natural: el ítem al tope de cada columna es el de mayor prioridad. El equipo usa el método FIFO (First In, First Out): cada nueva tarea que entra a un estado se coloca al final de la columna, y el siguiente ítem a tomar es siempre el del tope de la columna anterior.

Esto elimina el multitasking y el context switching porque cada persona sabe exactamente qué sigue.

Evaluación de capacidad real#

Con todas las tareas visibles en un solo tablero, responder "¿podemos tomar más trabajo?" es directo: si todas las personas del equipo ya están trabajando en algo, las nuevas solicitudes —no urgentes— deben esperar hasta que algo se complete. Cada "sí" a algo nuevo es un "no" a algo existente, generando deuda de flujo.

Forecasting con Montecarlo#

Un solo tablero concentra todos los datos de desempeño del equipo, lo que permite usar simulación Monte Carlo para generar forecasts probabilísticos de entrega. La simulación corre miles de iteraciones usando datos históricos de Throughput para producir un rango de fechas de entrega con su probabilidad asociada.

No se necesita que los ítems tengan tamaño uniforme ni un gran volumen de datos históricos. El único prerrequisito es tener el sistema optimizado para predictibilidad mediante WIP Limits y control de Aging.

En 23people#

En 23people implementamos este principio a través del Flujo Principal del tablero de cada equipo: una única puerta de entrada por donde ingresan todos los pedidos, incidencias, mejoras e iniciativas desde actores externos al equipo. La convención completa de uso está documentada en la Guía de Uso de Tableros Principales de Equipos.

Referencias#