Límites de WIP: Cómo Establecerlos en Kanban (Con Ejemplos)

Los límites de trabajo en progreso (WIP) son una de las formas más rápidas de mejorar la velocidad con que el trabajo avanza en un equipo. Se coloca un número sobre cada columna de su tablero Kanban, y la regla es simple: nadie comienza trabajo nuevo si la columna ya está en su límite.

Datos clave

• Los equipos que aplican límites de WIP reportan tiempos de ciclo 2 veces más rápidos que aquellos sin límites, según una encuesta de profesionales de Kanban University (2023).
• El cambio de contexto le cuesta a los trabajadores un promedio de 23 minutos para volver a concentrarse por completo después de una interrupción, lo cual se acumula cuando hay varias tareas en curso simultáneamente (Universidad de California, Irvine, 2023).
• El equipo de software promedio trabaja en de 3 a 5 tareas activas por persona a la vez, pero el rendimiento máximo típicamente se logra con 1 a 2 tareas por persona (State of Agile Report, 17.ª edición, 2024).

¿Qué son los límites de WIP?

Los límites de WIP (límites de trabajo en progreso) son topes explícitos sobre cuántos elementos pueden existir en una etapa determinada de un workflow al mismo tiempo. En un sistema Kanban, cada columna del tablero representa una etapa, y el límite de WIP se coloca sobre esa columna como un número. Cuando una columna alcanza su límite, nadie incorpora trabajo nuevo a ella hasta que algo avance.

El concepto proviene directamente de la manufactura lean, donde Toyota usaba un sistema llamado "tarjetas kanban" para controlar el flujo de producción en la planta de la fábrica. La idea era que la sobreproducción es un desperdicio, y el mismo principio aplica al trabajo del conocimiento: mientras más cosas comience sin terminar, más lento se vuelve todo.

Los límites de WIP no le dicen en qué trabajar a continuación. Le dicen cuándo dejar de comenzar cosas y empezar a terminar las existentes.

¿Por qué limitar el trabajo en progreso?

El argumento a favor de los límites de WIP se basa en una fórmula llamada la Ley de Little, que establece:

Tiempo de ciclo = WIP / Rendimiento

En términos simples: si su equipo tiene 20 elementos en progreso y completa 5 por semana, el tiempo de ciclo promedio es de 4 semanas. Reduzca el WIP a 10 elementos y el tiempo de ciclo cae a 2 semanas, sin que el equipo trabaje más duro.

La matemática suena casi demasiado limpia, pero el mecanismo subyacente es real. Esto es lo que sucede sin límites:

El cambio de contexto mata la concentración. Cada vez que alguien toma una tarea nueva antes de terminar una antigua, paga un costo mental de cambio. Ese costo no es trivial. La investigación de UC Irvine lo sitúa en más de 20 minutos de concentración perdida por interrupción. Multiplique eso por 3 a 5 tareas concurrentes por persona y habrá consumido silenciosamente la mayor parte de una jornada laboral solo en carga de transición.

Las colas largas ocultan problemas. Cuando el trabajo se acumula en una columna, se vuelve invisible. Nadie nota que una tarea de revisión ha estado sin tocar durante tres días, porque el tablero está tan saturado que el retraso no se destaca. Los límites de WIP exponen estos cuellos de botella de inmediato. Si la columna "En revisión" alcanza su tope, el equipo tiene que hablar sobre por qué los elementos no avanzan.

Las métricas de flujo reflejan esto directamente. Si está usando un diagrama de flujo acumulado, las bandas anchas en las etapas intermedias son una señal visual de WIP alto. Las bandas estrechas y paralelas significan que el WIP está bajo control y el trabajo está fluyendo. El velocity en agile también tiende a mejorar una vez que los límites de WIP estabilizan cuánto se compromete el equipo por ciclo.

Cómo establecer límites de WIP

No existe una fórmula universal que funcione para todos los equipos. Pero estos pasos le dan un punto de partida que puede ajustar con el tiempo.

Paso 1: Cuente la capacidad de su equipo

Comience con el número de personas que trabajan en cada etapa. Una columna de desarrollo con 4 desarrolladores puede manejar más elementos concurrentes que una columna de revisión con 1 o 2 personas.

Una regla inicial común: 2 elementos por persona por columna. Así, una columna de desarrollo con 4 personas comienza con un límite de WIP de 8.

Paso 2: Observe su WIP real actual

Antes de establecer cualquier límite, cuente cuántos elementos hay realmente en cada columna hoy. Esta es su línea base. Si la columna "En progreso" ya tiene 14 elementos para un equipo de 3 personas, tiene una imagen clara de por qué el trabajo tarda tanto en completarse.

Paso 3: Establezca los límites ligeramente por debajo de su promedio actual

Si su WIP promedio por columna es de 10, comience su límite en 7 u 8, no en 3. Un límite demasiado ajustado causa más disrupción de la que resuelve, especialmente al principio. Quiere que el equipo sienta la restricción y responda, no que se sienta paralizado.

Paso 4: Aplique el límite como disparador de conversación, no como bloqueo estricto

Cuando una columna alcanza su límite, el trabajo del equipo es concentrarse en el trabajo bloqueado y despejarlo antes de incorporar algo nuevo. Aquí es donde los límites de WIP cambian el comportamiento del equipo. "¿Podemos ayudar a que este elemento pase la revisión?" se convierte en un hábito diario en lugar de una idea tardía.

Paso 5: Revise y ajuste cada dos semanas

Después de dos sprints o dos semanas, revise su gráfico de burndown y los datos de tiempo de ciclo. Si los elementos están fluyendo más rápido, ajuste los límites hacia abajo. Si el equipo se siente constantemente bloqueado, relájelos un poco. Los límites de WIP son un dial, no una regla grabada en piedra.

Límites de WIP por columna del tablero

Aquí hay una tabla de referencia para un equipo de software típico que usa un tablero Kanban de cuatro columnas. Estos son puntos de partida, no prescripciones.

Para un equipo de 4 desarrolladores, una configuración inicial razonable es: Por hacer (sin límite), En progreso (6), En revisión (3), Terminado (sin límite). Eso evita que la columna de desarrollo se convierta en un cuello de botella y obliga a que la revisión se mantenga ágil.

Si su equipo usa Scrum con sprints de dos semanas, puede aplicar los límites de WIP al tablero de sprint de la misma manera. La lógica es idéntica, aunque el enfoque difiera. La distinción entre Scrum y Kanban no cambia la matemática subyacente de la Ley de Little.

Errores comunes al establecer límites de WIP

Establecer límites e ignorarlos. Un límite de WIP que la gente evita no existe. Si el equipo anula regularmente el tope con "excepciones", el límite no se está aplicando. Construya el hábito antes de construir el proceso.

Aplicar un mismo número a cada columna. Una columna de revisión con 2 revisores y una columna de desarrollo con 5 desarrolladores tienen rendimientos completamente diferentes. Aquí una talla no le queda a nadie.

Hacer el límite demasiado bajo demasiado rápido. Si baja de 15 elementos por columna a 3 de la noche a la mañana, creará pánico y resistencia. Un ajuste gradual le da al equipo tiempo para adaptar sus workflows y sacar a la luz los problemas que el WIP alto estaba ocultando.

Olvidarse de los bloqueadores. Los límites de WIP también cuentan los elementos bloqueados. Si 3 de sus 6 tareas "En progreso" están bloqueadas por dependencias externas, en realidad solo tiene 3 espacios de capacidad real. Rastrear los bloqueadores por separado ayuda a mantener una imagen precisa.

No ajustar según los story points. Algunos equipos establecen límites por conteo de elementos, otros por story points. Si sus tareas varían mucho en tamaño (una tarea de 1 punto junto a un épico de 13 puntos), cuenten por puntos para obtener una imagen más honesta de la carga.

Beneficios de los límites de WIP

Cuando los equipos realmente aplican sus límites, ocurren algunas cosas de forma consistente:

El trabajo termina más rápido. El tiempo de ciclo cae porque los elementos no se quedan esperando. Cuando el equipo solo puede tener 5 cosas en progreso, cada uno de esos 5 elementos recibe atención diaria.

Los cuellos de botella se vuelven visibles de inmediato. Una columna que siempre está en su límite le está diciendo algo. El equipo no puede ignorarlo porque está bloqueando todo lo demás.

Las conversaciones de equipo mejoran. Los límites de WIP crean momentos naturales para preguntar "¿por qué está atascado esto?" en lugar de dejar que los retrasos se vuelvan invisibles. Los standups diarios se enfocan más en la misma pregunta: ¿qué está bloqueando el progreso en este momento?

La planificación se vuelve más honesta. Cuando el equipo ve una columna llena, deja de comprometerse con trabajo nuevo que no puede manejar. El sobrecompromiso disminuye y el pronóstico mejora. Esto se conecta directamente con cómo se estabiliza el velocity en agile una vez que el WIP está bajo control.

El estrés disminuye. De forma contraintuitiva, que le digan "solo puede trabajar en 5 cosas" es menos estresante que le digan "termine las 15". Las personas saben en qué enfocarse.

Preguntas frecuentes

¿Qué es un límite de WIP en Kanban? Un límite de WIP es un número colocado sobre una columna de Kanban que acota cuántos elementos de trabajo pueden existir en esa etapa a la vez. Cuando una columna alcanza su límite, los miembros del equipo deben ayudar a despejar el trabajo existente antes de incorporar algo nuevo.

¿Cómo se calcula el límite de WIP correcto? Comience con 2 elementos por persona en cada columna, luego observe durante dos semanas. Si el trabajo está fluyendo y los tiempos de ciclo están mejorando, ajuste el límite hacia abajo. Si el equipo se siente crónicamente bloqueado, relájelo. No hay un único número correcto. El objetivo es encontrar la restricción que saque a la luz los cuellos de botella sin paralizar el rendimiento.

¿Pueden los límites de WIP aplicarse fuera de Kanban? Sí. Los equipos Scrum aplican límites de WIP a los tableros de sprint. Incluso los equipos que usan métodos híbridos o listas de tareas simples pueden beneficiarse de un tope informal sobre cuántas cosas maneja cada persona a la vez. La lógica subyacente, la Ley de Little, aplica a cualquier sistema de colas.

¿Qué pasa cuando se alcanza un límite de WIP? El equipo deja de incorporar trabajo nuevo a esa columna y se enfoca en despejar los elementos existentes. En la práctica, esto a menudo significa concentrarse en una tarea bloqueada o hacer una revisión improvisada para desbloquear a alguien más adelante en el flujo. El límite crea urgencia sin requerir que un manager intervenga.

¿Debería la columna "Por hacer" tener un límite de WIP? Generalmente no, o al menos no uno estricto. Por hacer funciona como un backlog. Un tope flexible (como 2x la capacidad del sprint) puede evitar que la columna se convierta en un vertedero, pero un límite estricto tiende a crear urgencia artificial en elementos que aún no están listos para trabajarse.

---

Los límites de WIP son un cambio pequeño con un efecto desproporcionado en el flujo del equipo. Una vez que ve un cuello de botella salir a la luz por primera vez porque una columna alcanzó su tope, el mecanismo hace clic. A partir de ahí, es solo cuestión de ajustar los números. Rastree sus tiempos de ciclo con un diagrama de flujo acumulado y observe qué pasa con las bandas cuando el WIP baja.