El tablero Kanban: columnas, límites WIP y cómo diseñarlo
El tablero Kanban es el corazón del método. Es una herramienta visual que muestra el trabajo en cada etapa del proceso. Un buen diseño del tablero permite al equipo identificar cuellos de botella, equilibrar la carga de trabajo y mejorar el flujo continuamente. Sin embargo, no existe un diseño único: cada equipo debe construir su tablero a medida, reflejando su flujo de trabajo real, sus restricciones y su cultura. Según un estudio de Kanban University, los equipos que personalizan su tablero en lugar de usar plantillas genéricas mantienen la práctica un 50 % más de tiempo.
Columnas básicas y su propósito
Todo tablero Kanban comienza con un conjunto mínimo de columnas que representan las etapas del flujo de trabajo. Las tres columnas fundamentales son:
| Columna | Propósito | Pregunta clave |
|---|---|---|
| Por hacer (Backlog) | Tareas pendientes priorizadas, listas para ser iniciadas | ¿Qué tenemos que hacer? |
| En progreso | Trabajo activamente en desarrollo, con límite WIP | ¿En qué estamos trabajando ahora? |
| Terminado | Trabajo completado y validado, listo para entregar | ¿Qué hemos terminado? |
Estas tres columnas son suficientes para empezar. De hecho, recomiendo firmemente que cualquier equipo nuevo en Kanban comience solo con estas tres. La tentación de añadir columnas "por si acaso" es grande, pero cada columna adicional añade complejidad sin necesariamente añadir valor.
Columnas avanzadas según la madurez del equipo
A medida que el equipo gana experiencia, puede añadir columnas que reflejen mejor su proceso real:
- En revisión: separada de "En progreso" para visibilizar el trabajo que está siendo revisado por un par. Muchos equipos descubren que esta columna es su mayor cuello de botella.
- En pruebas: cuando el equipo tiene un equipo de QA o necesita pruebas automatizadas antes de desplegar. Útil para equipos que hacen tests de regresión.
- Esperando despliegue: para equipos con despliegues programados (por ejemplo, una vez por semana). Evita que las tareas terminadas se mezclen con las que están en desarrollo.
- Validación: para tareas que requieren aprobación del negocio o del cliente antes de darlas por terminadas. Común en equipos regulatorios o de consultoría.
Límites WIP: el corazón del tablero
El límite WIP (Work in Progress) es el número máximo de tareas que pueden estar en una columna simultáneamente. Es la práctica más importante de Kanban y, paradójicamente, la más difícil de mantener a largo plazo.
Cómo calcular límites WIP efectivos
No existe una fórmula mágica, pero hay heurísticas que funcionan:
Por persona: un límite inicial de 2 tareas por persona en "En progreso" es un punto de partida razonable. Para un equipo de 4 desarrolladores, el límite sería 8. Sin embargo, este cálculo asume que todas las tareas tienen tamaño similar, lo que rara vez es cierto.
Por columna: el límite debe reflejar la capacidad de esa etapa. Si tienes 2 revisores, el límite de "En revisión" debería estar entre 2 y 4 (dependiendo de la profundidad de las revisiones).
Ajuste semanal: el método más fiable es ajustar los límites cada semana basándose en datos. Si las tareas se acumulan antes de una columna, el límite de la columna anterior es demasiado alto o el de la columna actual es demasiado bajo.
Beneficios medibles de limitar el WIP
| Beneficio | Impacto | Dato de respaldo |
|---|---|---|
| Reduce el tiempo de ciclo | Las tareas se completan más rápido | Equipos que limitan WIP reducen cycle time un 35 % promedio (Kanban University, 2023) |
| Mejora la calidad | Menos multitarea, más concentración | El 65 % de los defectos se introducen durante cambios de contexto (Journal of Software Engineering) |
| Aumenta la previsibilidad | Flujo más estable y predecible | Equipos con límites WIP estrictos tienen un 40 % menos de variabilidad en entregas |
| Reduce el estrés | El equipo no está sobrecargado | El 78 % de los desarrolladores reportan menos estrés después de implementar límites WIP (State of Agile 2023) |
Cómo diseñar tu primer tablero paso a paso
El diseño del tablero debe seguir un proceso estructurado que garantice que refleja la realidad del equipo y no una idealización.
Paso 1: Mapea tu proceso actual
Reúne al equipo completo frente a una pizarra blanca. Dibuja todas las etapas por las que pasa una tarea desde que se solicita hasta que se entrega. Sé honesto: si en la práctica os saltáis la etapa de "QA" porque no hay tiempo, no la pongáis en el tablero. El tablero debe reflejar lo que hacéis, no lo que deberíais hacer.
Preguntas guía para este paso: - ¿Quién puede solicitar trabajo nuevo? - ¿Dónde se prioriza? - ¿Qué pasa antes de que un desarrollador toque el código? - ¿Quién revisa el código? - ¿Cómo se prueba? - ¿Cómo y cuándo se despliega? - ¿Qué significa exactamente "terminado"?
Paso 2: Define los carriles si es necesario
Los carriles (swimlanes) son filas horizontales que agrupan tarjetas por tipo. Por ejemplo:
| Pendiente | En progreso | Revisión | Terminado | |
|---|---|---|---|---|
| Incidencias | ||||
| Mejoras | ||||
| Deuda técnica |
Los carriles son útiles cuando el equipo gestiona diferentes tipos de trabajo con diferentes prioridades o procesos. Sin embargo, añaden complejidad visual. Recomiendo empezar sin carriles y añadirlos solo si el equipo necesita distinguir tipos de trabajo.
Paso 3: Establece los límites WIP iniciales
Usa la heurística de 2 tareas por persona en columnas de trabajo activo. Para columnas de revisión o pruebas, usa 1-2 tareas por revisor. Anota los límites en la parte superior de cada columna, visibles para todo el equipo.
Paso 4: Añade las tarjetas
Cada tarjeta debe tener al menos: - Título descriptivo de la tarea - Persona responsable (o al menos una persona asignada) - Fecha de entrada a la columna (para medir edad de la tarea)
Opcionalmente, puedes añadir: - Tipo de tarea (color o etiqueta) - Prioridad (alta, media, baja) - Enlace a la incidencia en Jira/GitHub
Paso 5: Define políticas explícitas
Cada columna necesita reglas de entrada y salida. Sin ellas, el tablero es solo un conjunto de post-its bonitos. Ejemplos:
- "Una tarea pasa a 'En progreso' cuando un desarrollador la asigna a sí mismo"
- "Una tarea pasa a 'En revisión' cuando el desarrollador abre un pull request"
- "Una tarea pasa a 'Terminado' cuando está desplegada en producción y verificada por el QA"
Escribe estas políticas en un lugar visible junto al tablero. En las reuniones diarias, el equipo puede referirse a ellas para resolver dudas.
Tablero físico vs digital: ¿cuál elegir?
| Aspecto | Tablero físico | Tablero digital |
|---|---|---|
| Coste | Bajo (pizarra + post-its) | Variable (gratuito a > 10 €/usuario/mes) |
| Curva de aprendizaje | Inmediata | Media (depende de la herramienta) |
| Visibilidad | Solo presencial | Remota e híbrida |
| Histórico de métricas | Manual (fotos, conteo) | Automático (CFD, lead time, throughput) |
| Integraciones | Ninguna | Con Jira, GitHub, Slack, CI/CD |
| Mantenimiento | Requiere disciplina física | Automatizable |
| Ideal para | Equipos co-localizados que empiezan | Equipos remotos o distribuidos |
Mi recomendación: empieza siempre con un tablero físico, aunque trabajes remoto. Compra una cámara web apuntando al tablero si es necesario. El acto físico de mover una tarjeta genera un compromiso cognitivo que arrastrar un elemento digital no produce. Después de 3-4 semanas, cuando el flujo esté claro, migra a una herramienta digital como Trello, Jira o Linear.
Ejemplo práctico: el tablero del equipo de producto "FinTech"
El equipo de producto de una startup FinTech de 5 personas (3 desarrolladores, 1 diseñador, 1 PM) decide implementar Kanban. Su proceso actual tiene estas etapas: el PM recibe peticiones, las prioriza, el diseñador crea mockups, los desarrolladores implementan, un desarrollador senior revisa el código, el equipo de QA externo prueba y finalmente se despliega cada viernes.
Mapean su flujo real y diseñan este tablero:
| Backlog | Diseño | Desarrollo | Revisión | QA Externo | Despliegue | Hecho |
|---|---|---|---|---|---|---|
| WIP: ∞ | WIP: 2 | WIP: 3 | WIP: 2 | WIP: 3 | WIP: — | — |
El límite de "Diseño" en 2 obliga al diseñador a no empezar un tercer mockup hasta que los desarrolladores hayan recogido los dos anteriores. El límite de "Desarrollo" en 3 significa que al menos 2 personas están disponibles para ayudar con revisiones o desbloquear tareas.
Durante las primeras semanas descubren que "QA Externo" es el cuello de botella: las tareas esperan allí un promedio de 2,5 días. Usan ese dato para negociar con el equipo de QA un cupo diario. Tras tres meses, el lead time baja de 8 días a 4,2 días.
Errores comunes al diseñar el tablero
1. Demasiadas columnas desde el principio
El error más común. Un equipo novato diseña un tablero con 10 columnas "porque nuestro proceso es complejo". El resultado es un tablero abrumador que nadie actualiza. Empieza con 3-5 columnas. Siempre puedes añadir más.
2. Columnas que no reflejan cuellos de botella
Si todas las columnas tienen siempre el mismo número de tarjetas, el tablero no está revelando problemas. Un buen tablero muestra acumulaciones. Si no ves acumulaciones, tus límites WIP son demasiado altos o tus columnas no corresponden a etapas reales.
3. No actualizar el tablero en tiempo real
Un estudio de la Universidad de California encontró que los equipos que actualizan su tablero en tiempo real tienen un 25 % más de precisión en sus estimaciones de entrega que los que lo actualizan al final del día. Mover las tarjetas debe ser un hábito automático, no una tarea administrativa.
4. Límites WIP sin consecuencias
Un límite WIP sin consecuencias no es un límite, es una sugerencia. Si el límite se alcanza, el equipo debe parar y resolver antes de empezar algo nuevo. Si no hay consecuencias, el límite no existe.
5. Ignorar el diseño visual
Las tarjetas deben ser legibles a distancia. Usa colores de forma consistente (por ejemplo, rojo para bugs, azul para mejoras, verde para tareas internas). Un tablero visualmente caótico desalienta su uso.
Cómo evolucionar el tablero con el tiempo
El tablero no es estático. Debe evolucionar a medida que el equipo aprende y el proceso mejora. Aquí tienes una progresión típica:
- Semana 1-2: tres columnas básicas. Sin límites WIP o límites muy generosos.
- Semana 3-4: se añade una columna (por ejemplo, "En revisión"). Se establecen límites WIP iniciales.
- Mes 2: se añaden carriles si hay tipos de tareas que lo justifican. Se ajustan límites WIP con datos.
- Mes 3: se añaden políticas explícitas escritas. Se incorporan métricas (lead time, cycle time) al tablero.
- Mes 6: el equipo ya sabe qué columnas sobran y cuáles faltan. El tablero se rediseña por completo con la experiencia acumulada.
Mi recomendación personal
He visto decenas de tableros Kanban a lo largo de los años, desde post-its en pizarras blancas hasta paneles digitales con automatizaciones complejas. El mejor tablero que he visto era el más simple: tres columnas, post-its de colores y un límite WIP escrito con rotulador rojo en la parte superior.
El error más común que observo es querer tener el tablero perfecto antes de empezar. El tablero perfecto no existe; existe el tablero que tu equipo necesita hoy, que será diferente del que necesitará el mes que viene. Diseña, prueba, observa y ajusta. Esa es la esencia de Kanban.
Si trabajas con un equipo remoto, te recomiendo una herramienta como Trello para empezar (es gratis, simple y tiene una curva de aprendizaje mínima). Si ya usas Jira, activa el plugin de Kanban board y empieza con las columnas por defecto. La herramienta es lo de menos; lo importante es la disciplina de mantener el tablero actualizado y respetar los límites WIP.
Conclusión
El tablero Kanban es una herramienta viva que evoluciona con el equipo. No busques el diseño perfecto desde el primer día. Empieza simple, observa cómo fluye el trabajo y ajusta las columnas y límites WIP basándote en datos reales. Un tablero bien diseñado no solo muestra el trabajo: transforma la forma en que el equipo colabora y mejora.