Una lista de verificación para el viernes: poner a trabajar los límites de WIP en Scrum
Muchos equipos que se recuperaron de lo peor de la disrupción pandémica se encontraron con el problema contrario: demasiado empezado y muy poco terminado. El trabajo remoto e híbrido facilitaba tomar otro elemento en lugar de ayudar a cerrar uno, y el trabajo a medias se acumulaba a lo largo del sprint. Scrum no prohíbe un remedio aquí: la Guía de Scrum guarda deliberadamente silencio sobre cómo un equipo gestiona su flujo dentro de un Sprint, lo que deja espacio para tomar prestada la idea más útil del kanban: limitar el trabajo en curso.
Un límite de trabajo en curso (WIP) es simplemente un tope sobre cuántos elementos pueden estar a la vez en una columna del tablero. Cuando la columna está llena, la regla es dejar de empezar y empezar a terminar: el equipo se vuelca sobre lo que ya avanza antes de tomar algo nuevo. Es una restricción pequeña con un efecto desmesurado sobre la previsibilidad, y no exige cambiar roles, eventos ni el Sprint en sí.
Antes de fijar un límite
Haz honesto tu tablero: cada estado real por el que pasa un elemento (p. ej. En análisis, En desarrollo, En revisión, En pruebas) debería tener su propia columna, no esconderse dentro de un gran « Haciendo ».
Observa una semana sin ningún límite y cuenta cuántos elementos hay en promedio en cada columna por día. Ese promedio es tu referencia inicial, no una meta.
Acuerden como equipo qué significa « terminado en esta columna », para que un elemento la abandone de verdad antes de tomar el siguiente.
Decidan quién puede romper un límite y cuándo: la respuesta debería ser « casi nunca, y solo por acuerdo del equipo ».
La lista que puedes aplicar esta semana
Elige una sola columna cuello de botella. No limites todas las columnas a la vez. Escoge aquella donde los elementos se acumulan visiblemente —a menudo Revisión o Pruebas— y empieza ahí.
Fija el primer límite ligeramente por debajo de tu promedio observado. Si Revisión suele tener cuatro elementos, prueba con tres. La leve incomodidad es el objetivo: saca a la luz el problema del traspaso en vez de ocultarlo.
Haz visible el límite. Escríbelo en la parte superior de la columna en el tablero físico o digital para que nadie lo supere por descuido.
Define la respuesta de enjambre. Cuando se alcance el límite, acuerden qué hace la gente en lugar de empezar trabajo nuevo: emparejarse en el elemento bloqueado, revisar el pull request de un compañero o resolver una dependencia.
Habla de los incumplimientos en el Scrum diario. Si ayer se superó el límite, pregunta por qué. La respuesta suele ser un traspaso atascado, un criterio de aceptación poco claro o una dependencia de alguien externo al equipo.
Ajusta en la Retrospectiva, no a mitad de Sprint. Modifica el número según lo aprendido, en pasos pequeños. Bajar demasiado un límite paraliza el tablero; subirlo demasiado vuelve inútil el tope.
Cómo se ve el éxito
Tras unos pocos Sprints deberías ver menos elementos en curso en cualquier momento, menos tiempo entre el inicio y el final de cada elemento, y una Revisión de Sprint donde la mayor parte de lo tomado está realmente terminado y no « casi listo ». El Objetivo del Sprint se vuelve más fácil de defender porque el equipo converge hacia él en lugar de dispersarse. Si un límite se combate constantemente, tómalo como un dato: señala una restricción real —una aprobación lenta, un único especialista sobrecargado, una dependencia externa— que conviene corregir en su origen en vez de sortear.
Nada de esto reemplaza a Scrum; lo afina. Los límites de WIP dan a los Desarrolladores un mecanismo concreto y diario para proteger el foco y hacer visible el flujo de valor, que es justo lo que un Sprint debe producir.
Si tus equipos de entrega empiezan más de lo que terminan y quieres ayuda para convertir el flujo en un hábito duradero, la asesoría de entrega de programas y proyectos de XNM puede ayudarte a ponerlo en práctica.