Ir al contenido principal

Trabajo en curso (WIP)

El trabajo en curso (WIP) es cuántos ítems tiene el equipo en vuelo. Un WIP alto es la señal temprana más confiable de cambio de contexto, sobrecarga y entregas que se frenan.


​

Qué mide


​

Un conteo de las tareas empezadas y no terminadas. Es una foto, no un promedio del período: un número que describe cómo están las cosas al final de la ventana seleccionada.


​

Cómo lo calcula Leanmote


​

Una tarea cuenta como trabajo en curso cuando la categoría de su estado más reciente no es ni backlog ni terminal:


​

Categoría del estado más reciente

¿Cuenta como WIP?

Backlog (kind 0)

No

Hecho o cancelado (kinds 3 y 4)

No

Cualquier otra

Sí


​

  • Las categorías salen del mapeo de estados del board: ahí es donde se clasifica cada estado de tu herramienta. Leanmote no mantiene una lista propia de nombres de estados "activos", así que un estado nuevo entra por la categoría a la que lo mapees.

  • Cancelado también es terminal. Antes de que eso quedara explícito, los ítems cancelados se contaban como en curso para siempre.

  • Las tareas de boards excluidos se saltean.

  • Las tareas sin ningún historial de estados quedan aparte: no se pueden ubicar.


​

Dos cosas que conviene dejar claras, porque son fáciles de suponer:


​

  • No existe un WIP promedio. Leanmote informa el conteo, no una serie muestreada en el tiempo, así que no se puede leer "WIP promedio del trimestre" en esta métrica.

  • La asignación no forma parte de la regla. Una tarea sin responsable en un estado activo cuenta igual.


​

Cómo interpretarlo


​

  • WIP subiendo más rápido que el throughput es la señal clásica de cuello de botella. El cycle time sube después.

  • WIP muy por encima del tamaño del equipo suele significar que se están malabareando demasiados ítems a la vez. El costo del cambio de contexto es invisible pero real.

  • WIP cerca de cero con throughput estable puede ser sano: el equipo termina lo que empieza. Solo conviene verificar que las transiciones de estado se estén registrando; un board con estados sin mapear produce la misma foto.


​

Qué hacer al respecto


​

  • Define límites de WIP explícitos por etapa. El patrón más común es límite ≤ tamaño_del_equipo + 1.

  • Flujo por arrastre: no empieces un ítem nuevo hasta terminar uno en vuelo.

  • Si el WIP se concentra en una etapa, por ejemplo revisión, invierte ahí primero.

  • Haz visible el WIP en el ritual diario del equipo, para que no sea solo una métrica de liderazgo.


​

Ley de Little


​

WIP, throughput y cycle time están ligados por la Ley de Little: cycle_time ≈ wip / throughput. Si no puedes subir el throughput, la única forma de acortar el cycle time es bajar el WIP.


​

Métricas relacionadas


​

  • Throughput

  • Cycle Time

  • Avg Member WIP Age — hace cuánto están sentados los ítems en vuelo

  • Panorama de métricas de flujo

¿Ha quedado contestada tu pregunta?