Tablero kanban de flujo libre

Fernando Cañas — Sun, 26 Apr 2026 16:29:28 +0000

Luego de varias iteraciones creando tableros kanban para equipos de desarrollo, finalmente logré crear uno con el que me siento cómodo. No sólo yo como Product Manager, también mi equipo de desarrollo.

El tablero tiene 9 columnas, agrupadas en 5 estados.

Estados

Los estados por los que pasa una tarjeta son:

Análisis
Diseño
Ejecución
Revisión
Hecho

Análisis (Qué + Por qué)

Esta etapa se dedica al "qué" y el "por qué". Es decir, si se va a construir algo nuevo, hay que plantear en concreto "qué" se desea construir y "por qué" es importante.

Si hay un error del sistema que hay que corregir, hay que determinar en concreto cuál es el error y por qué está ocurriendo, en qué circunstancias. Por qué los tests no lograron captar el error en primer lugar.

Si se va a cambiar el diseño de una interfaz, qué se quiere cambiar y por qué es importante para la experiencia de usuario.

En conclusión, esta etapa permite pensar el problema para precisarlo y ser capaces de justificar la necesidad de resolverlo.

Diseño (Cómo)

Cuando un problema está definido, tanto en el qué es lo que se quiere resolver y por qué, ya se pueden empezar a crear posibles soluciones. Esto ocurre en la etapa de diseño.

En esta etapa se generan alternativas, que puedan ser evaluadas en conjunto por el equipo hasta escoger una.

Ejecución

Con un análisis claro del problema y el diseño escogido para resolverlo, esta etapa se dedica a construir la solución. Como su nombre lo indica, es el momento de ejecutar sobre lo analizado y decidido.

Revisión

Esta etapa no sólo revisa los resultados de la ejecución. También revisa los entregables de las etapas de análisis y diseño.

Una tarjeta en el tablero puede pasar varias veces por esta etapa de revisión.

Cuando un análisis se estima ya completado, pasa a revisión. Si la revisión considera que no es así y se requiere mayor detalle, que existen puntos de análisis faltantes, entre otros, la tarjeta regresa a la etapa de análisis.

Lo mismo ocurre con los diseños. Cuando se estima que están completos, pasan a revisión. Si la revisión concluye que no es así, la tarjeta regresa para extensiones o correcciones al diseño.

Con los entregables de la ejecución ocurre igual.

Hecho

Las tarjetas pasan a hecho cuando se han superado las 4 etapas anteriores o cuando en cualquier punto del camino se toma la decisión de no seguir adelante con una tarjeta. Esta segunda opción debería ir acompañada de su correspondiente justificación (el por qué no justifica la inversión, el alcance del proyecto se redujo, el diseño reveló restricciones que hacen inviable en el corto plazo la implementación, entre otros).

9 Columnas

El tablero tiene 9 columnas porque casi todas las etapas requieren dos columnas. Una de espera y otra de actividad.

Las columnas de espera es donde están las tarjetas que se encuentran en una etapa en particular, pero que no están siendo atendidas en ese momento por nadie. Es decir, están a la espera de ser resueltas.

Las columnas de actividad están las tarjetas que en ese mismo instante están siendo trabajadas por alguien del equipo. Al ver en el tablero qué tarjetas están en las columnas de actividad permite saber rápidamente qué tareas está trabajando el equipo en ese instante.

Por lo tanto, las 9 columnas serían:

🕐 Cola de análisis
🤔 Analizando
🕐 Cola de diseño
✏️ Diseñando
🕐 Cola de ejecución
💻 Ejecutando
🕐 Cola de revisión
🔎 Revisando
✅ Hecho

Sin orden estricto

Por lo general, una tarjeta primero se analiza, luego se diseña y finalmente se ejecuta. En el intermedio, va pasando varias veces por revisión hasta cumplir con cada etapa.

Sin embargo, el tablero no pretende que todas las tarjeta siempre deban pasar por este orden. De hecho:

Una tarjeta puede nacer en cualquier columna.
Una tarjeta puede pasar múltiples veces por la misma etapa.
Una tarjeta puede circular por las etapas en cualquier orden.

Lo anterior puede ocurrir porque las tarjetas pueden intentar resolver temas de distinto tipo. No es lo mismo construir una funcionalidad nueva que ajustar una configuración.

También puede ocurrir porque hay proyectos que son tan grandes que se decide crear tarjetas separadas por tema o inclusive tarjetas por etapa.

El tablero no obliga a que las tarjetas fluyan de una manera específica. El tablero es una herramienta para que el equipo piense y ejecute de forma ordenada, no una línea de producción industrial.

Cola vs. Actividad

Cuando una tarjeta está en la cola es porque no está siendo atendida. Es la persona que va a trabajar la tarjeta quien mueve la tarjeta a la columna de actividad.

Esto actúa como señal para todo el equipo, de tal forma que se sabe que acaba de empezar a trabajar en esa tarjeta.

Si por alguna razón ocurre un bloqueo que impide continuar la ejecución de una tarjeta, el responsable anota la causal del bloqueo y regresa la tarjeta a la columna de cola.

Reasignación

El responsable de asignar tarjetas puede asignar tarjetas con libertad cuando estas están en una columna de cola. No puede hacerlo cuando está en una columna de actividad.

Para poder reasignar una tarjeta que está en actividad, se requiere del acuerdo con la persona que está trabajando en ella.

Generalización

Este tablero me ha sido útil para tareas de desarrollo. Sin embargo, las etapas que presento no están estrictamente relacionadas con actividades propias del desarrollo de software: "desarrollo", "testing", "deployment", "qa", etc.

Por lo tanto, creo que este diseño puede resultarle útil a equipos que no sean específicamente de desarrollo de software. Puede serle útil a cualquier equipo cuya producción se base en el análisis de problemas y en el diseño e implementación su soluciones.

DEV Community: Fernando Cañas