3. Estructura del tablero Kanban

El tablero Kanban es el corazón del sistema. Su estructura hace visibles los compromisos del equipo, los puntos de espera y la carga de trabajo que fluye hacia la entrega.

3.1 Columnas típicas: «Por hacer», «En progreso», «Hecho»

Las columnas dividen el flujo en etapas comprensibles. La secuencia básica suele iniciar con una columna de entrada («Por hacer»), continuar con una o más columnas de trabajo activo («En progreso») y cerrar con una columna de salida («Hecho»).

• Por hacer: agrupa elementos priorizados listos para comenzar. Se alimenta con trabajo previamente refinado y con criterios de entrada claros.
• En progreso: puede subdividirse en etapas como «Diseño», «Desarrollo» y «Pruebas» para reflejar el proceso real y aplicar límites de WIP específicos.
• Hecho: incluye trabajo terminado y validado. Algunas implementaciones agregan columnas intermedias como «Listo para despliegue» para mostrar esperas externas.

Cada modificación en la estructura de columnas debe responder a una necesidad del flujo; agregar columnas sin propósito genera ruido y dificulta la lectura.

3.2 Tarjetas (cards): representación de tareas o unidades de trabajo

Las tarjetas encapsulan la información esencial de cada elemento. Deben contener un título breve, descripción, responsable y cualquier dato que facilite el seguimiento.

• Unidad de valor: una tarjeta representa algo que el cliente o usuario percibirá como valioso, ya sea una funcionalidad, un incidente resuelto o una tarea de mantenimiento.
• Tamaño adecuado: tarjetas demasiado grandes estancan el flujo; dividirlas evita tiempos de ciclo extensos y mejora la previsibilidad.
• Historial visible: registrar comentarios y bloqueos en la propia tarjeta documenta decisiones y acelera el traspaso de conocimiento.

En tableros digitales como Trello o sistemas corporativos, las tarjetas incluyen checklists, adjuntos y fechas objetivo que refuerzan la transparencia.

3.3 Swimlanes o carriles horizontales: clasificación por tipo de tarea o prioridad

Los swimlanes agregan una dimensión horizontal al tablero. Separan el trabajo según su naturaleza o urgencia, permitiendo gestionar flujos paralelos sin perder visibilidad.

• Clases de servicio: carriles dedicados a incidencias urgentes, trabajos regulatorios o solicitudes estándar ayudan a aplicar acuerdos específicos.
• Capas organizacionales: equipos multifuncionales pueden asignar un carril a cada producto o cliente crítico, reduciendo conflictos de prioridad.
• Análisis de capacidad: observar qué carriles se llenan primero ofrece pistas sobre dónde ajustar recursos o renegociar compromisos.

Es importante limitar la cantidad de carriles: demasiados dividen la atención y complican la lectura del tablero.

3.4 Colores, etiquetas y responsables en las tarjetas

Los elementos visuales complementan la información textual. Colores y etiquetas comunicán estados especiales sin necesidad de texto adicional.

• Etiquetas de tipo: un color para defectos, otro para mejoras y otro para tareas técnicas permite detectar tendencias de un vistazo.
• Indicadores de riesgo: iconos o banderas alertan sobre impedimentos, dependencias externas o vencimientos próximos.
• Responsabilidad clara: mostrar la persona o el rol que lidera la tarea evita ambigüedades y facilita reasignaciones cuando surge un bloqueo.

La clave es mantener un esquema visual estable y documentado en las políticas del tablero, para que cualquier miembro nuevo entienda el lenguaje de colores y etiquetas sin explicaciones adicionales.

3.5 Ejemplo visual de un tablero Kanban

Imagina un equipo que desarrolla una aplicación web. Su tablero está compuesto por las columnas «Backlog priorizado», «Diseño», «Desarrollo», «Pruebas», «Listo para desplegar» y «En producción». Cada columna tiene límites de WIP definidos y el tablero se divide en dos swimlanes: uno para funcionalidades y otro para incidencias críticas.

Las tarjetas de funcionalidades llevan etiquetas verdes; las incidencias utilizan etiquetas rojas. Cuando un desarrollador comienza una tarea, mueve la tarjeta a «Desarrollo» y marca su avatar como responsable. Si el límite de «Pruebas» se completa, el equipo detiene nuevas incorporaciones y colabora para liberar ese cuello de botella. Las políticas, visibles en un panel lateral, explican cómo solicitar ayuda, cómo escalar bloqueos y qué criterios debe cumplir una tarjeta para avanzar.

Este ejemplo sintetiza los elementos fundamentales: columnas alineadas con el flujo real, visualizaciones complementarias y acuerdos explícitos que guían el comportamiento del equipo.