El error más común al crear un tablero Kanban es diseñarlo como si fuera un tablero Scrum. El tablero Scrum representa los estados de las tareas de un sprint. El tablero Kanban representa el flujo de trabajo completo de un servicio. La diferencia no es cosmética — determina qué decisiones se pueden tomar con él.
01 · Primer pasoMapear el flujo real de trabajo.
Antes de dibujar ninguna columna, el equipo necesita describir cómo fluye el trabajo de principio a fin. No el flujo ideal — el flujo real. Esto significa preguntarse: ¿desde dónde viene el trabajo? ¿Qué etapas atraviesa? ¿Dónde espera? ¿Quién lo toca en cada etapa?
El resultado es una lista de etapas que refleja la realidad operativa del equipo. Para un equipo de software podría ser: Backlog → Análisis → Diseño → Desarrollo → Revisión de código → Testing → Despliegue → Hecho.
02 · Segundo pasoDiseñar las columnas del tablero.
Cada etapa del flujo se convierte en una columna del tablero. Las columnas de espera (donde el trabajo espera antes de pasar a la siguiente etapa activa) se representan como subcolumnas o columnas buffer.
Un diseño inicial sencillo puede tener columnas de entrada, activas y terminadas. A medida que el equipo madura en Kanban, el tablero evoluciona para reflejar con más precisión el flujo real. No hay que diseñar el tablero definitivo desde el primer día — es un sistema que mejora continuamente.
03 · Tercer pasoIdentificar los tipos de trabajo.
No todo el trabajo que entra al sistema tiene la misma naturaleza ni las mismas necesidades de gestión. Un tablero Kanban maduro diferencia los tipos de trabajo con tarjetas de distintos colores o iconos:
- Trabajo estándar: peticiones habituales con flujo normal.
- Urgencias: trabajo que necesita pasar por delante del resto.
- Trabajo fijo: compromisos con fecha inamovible.
- Mejoras internas: trabajo que no viene de peticiones externas.
Distinguir tipos de trabajo permite aplicar políticas diferentes a cada uno — y gestionar las urgencias sin que destruyan el flujo del resto.
04 · Cuarto pasoEstablecer límites de WIP iniciales.
Una vez definidas las columnas, el siguiente paso es establecer los límites de WIP para cada columna activa. El límite de WIP indica cuántas tareas pueden estar activas simultáneamente en esa etapa.
Para empezar, una regla práctica es establecer un límite de WIP igual al número de personas que trabajan en esa etapa. Si hay 3 desarrolladores, el límite de desarrollo podría ser 3. Esto asegura que cada persona tiene exactamente una tarea activa — ni más, ni menos.
05 · Quinto pasoDefinir las políticas de cada columna.
Cada columna necesita una política que defina cuándo una tarea puede entrar y cuándo puede salir. Sin estas definiciones, el tablero es ambiguo y cada persona lo interpreta de forma diferente.
La política de entrada define el criterio de "listo para entrar en esta columna". La política de salida define cuándo una tarea está terminada en esta etapa y puede avanzar. Estas políticas se hacen explícitas y visibles — en el tablero físico o en el digital.