La guía oficial del método Kanban.

Kanban no siempre tuvo un documento fundacional. Durante años, el método se transmitió a través de libros, cursos y comunidades de práctica sin un texto oficial de referencia. En 2020, Kanban University publicó la Guía Oficial del Método Kanban — el equivalente kanban de la Scrum Guide, pero con una filosofía diferente: describir el mínimo indispensable sin prescribir soluciones concretas.

Qué es la Guía Oficial del Método Kanban.

La Guía Oficial del Método Kanban (también llamada Kanban Guide) es un documento breve — unas pocas páginas — que define los principios y prácticas esenciales del método. Su objetivo no es explicar cómo implementar Kanban en cada contexto, sino establecer los fundamentos mínimos que distinguen Kanban de otras formas de gestión visual.

Una diferencia importante respecto a la Scrum Guide: la Guía de Kanban no define roles obligatorios, no prescribe reuniones fijas ni establece iteraciones. Kanban es un método evolutivo que se superpone al proceso existente del equipo.

Los principios del método Kanban.

La Guía organiza los principios en dos grupos. Los principios de gestión del cambio establecen cómo adoptar Kanban sin disrupciones: empezar con lo que se hace hoy, comprometerse con la mejora incremental y respetar los roles y responsabilidades actuales.

Los principios de prestación de servicios definen la orientación del método: entender las necesidades del cliente, gestionar el trabajo y no a las personas, y revisar continuamente el sistema para mejorarlo.

Estos principios son distintos a las prácticas — los principios explican el por qué, las prácticas el cómo.

Las seis prácticas generales de Kanban.

La Guía define seis prácticas generales que conforman el núcleo del método:

1. Visualizar el flujo de trabajo. Hacer visible el trabajo en un tablero compartido.
2. Limitar el trabajo en curso (WIP). Establecer límites explícitos por etapa del flujo.
3. Gestionar el flujo. Monitorizar y optimizar el movimiento del trabajo.
4. Hacer las políticas explícitas. Definir y publicar las reglas del sistema.
5. Implementar ciclos de feedback. Establecer cadencias regulares de revisión.
6. Mejorar y evolucionar colaborativamente. Usar el método científico para mejorar el sistema.

Los ciclos de feedback de Kanban.

La Guía describe varias cadencias — reuniones regulares con propósitos específicos — que configuran el sistema de feedback del equipo:

• Revisión diaria de Kanban: revisión breve del tablero para detectar bloqueos y coordinar el flujo.

• Reunión de reposición: decisión de qué trabajo nuevo entra al sistema.

• Revisión del riesgo: identificación de ítems con riesgo de no cumplir compromisos.

• Revisión del servicio: análisis del rendimiento del sistema en el último período.

• Retrospectiva: mejora del proceso y la cultura del equipo.

No todas las cadencias son obligatorias en todos los contextos — la Guía proporciona el menú, el equipo elige las que necesita según su madurez y situación.

Mirar el trabajo con la lente de Kanban (y seis ideas equivocadas)

Antes que el tablero, Kanban cambia la forma de mirar el trabajo. Todo parte de gestionar el trabajo y no a las personas: cuando algo va mal, la pregunta no es quién falló, sino qué condición del sistema lo hizo posible. Se nota en cuatro perspectivas:

• Flujo, no tareas. La pregunta deja de ser "¿están todos ocupados?" y pasa a ser "¿a qué velocidad avanza el trabajo hacia el cliente?".
• El WIP como riesgo, no como progreso. El trabajo en curso ha consumido esfuerzo y todavía no ha entregado valor; si las prioridades cambian, puede acabar en desperdicio. Por eso se limita: significado y beneficios de limitar el WIP.
• Los bloqueos como información. Un bloqueo que se repite, o que aparece siempre en la misma etapa, señala una debilidad del sistema, no solo un síntoma que tratar.
• La variabilidad como dato de diseño. Si unas tareas tardan mucho más que otras, quizá necesitan clases de servicio distintas.

Con esa lente se desmontan las ideas equivocadas más habituales:

• "Es solo un tablero". Sin límites de WIP, políticas explícitas, métricas de flujo y cadencias de revisión se usa una fracción del método.
• "No tiene roles". No hay roles obligatorios, pero en organizaciones maduras aparecen dos opcionales: Service Request Manager y Service Delivery Manager. Más en qué roles son necesarios en los equipos Kanban.
• "Es para equipos que no planifican". Tiene cadencias de planificación; lo que elimina es la planificación ficticia, porque los compromisos salen de datos históricos de flujo.
• "Es incompatible con Scrum". Los límites de WIP, el tiempo de ciclo y el throughput funcionan dentro de un sprint.
• "No sirve para trabajo complejo". Sin sprints que romper ni alcance cerrado, el sistema se ajusta cuando cambian las prioridades.
• "No tiene prioridades". Las clases de servicio tienen políticas explícitas de selección (se explican más abajo).

Cómo visualizar y gestionar el flujo cada día

Qué mostrar en el tablero

Cada tarjeta responde sin abrir nada qué es (título, tipo de trabajo, referencia), para quién (responsable, cliente, prioridad) y cuándo (inicio, fecha límite si la hay, tiempo en el estado actual).

Las columnas muestran su límite de WIP y cuántas tarjetas tienen ahora. Y hay señales para lo que pide atención: marca roja con fecha y motivo en las bloqueadas, color según antigüedad (verde, ámbar, rojo) y forma o color por clase de servicio.

Si hay que buscar los bloqueos, el tablero no funciona. Junto a él, tres números semanales dan más contexto que una reunión de estado: tiempo de ciclo medio por tipo de trabajo, throughput semanal e histograma de la distribución del tiempo de ciclo. Cómo montarlo paso a paso está en cómo crear un tablero Kanban.

Pull criteria: cuándo una tarjeta puede pasar a la siguiente columna

Son las condiciones explícitas que una tarjeta cumple antes de que la etapa siguiente la "tire" hacia sí: "criterios de aceptación completos antes de entrar en desarrollo", "revisión de pares antes de pasar a pruebas", "pruebas automatizadas en verde antes del despliegue".

Funcionan si son verificables, los acuerda el equipo, están a la vista y se revisan en la retrospectiva a partir de los bloqueos y defectos que se repiten. Evitan que avance trabajo incompleto y reducen el retrabajo.

Las tres preguntas de la revisión diaria

1. ¿Estamos fluyendo? Columnas en su límite o por encima, tarjetas estancadas, bloqueos sin responsable.
2. ¿Cumplimos los compromisos? Throughput frente a la media histórica, calidad acordada, elementos que van a incumplir su SLA si no se actúa ya.
3. ¿Está cambiando la demanda? Más urgencias de lo habitual, un tipo de trabajo que crece sin capacidad prevista, expectativas de plazo distintas. La respuesta madura es ajustar políticas, capacidad y SLA, no cargar más al equipo.

Los siete desperdicios que el flujo deja a la vista

Los siete desperdicios que Taiichi Ohno identificó en Toyota tienen su versión en software, y Kanban los ataca así:

• Inventario (funcionalidades a medias, ramas sin integrar) y movimiento (cambios de contexto): los reducen los límites de WIP.
• Sobreproducción (construir lo que nadie usa): una cola visible con priorización explícita obliga a decir por qué se hace esto ahora.
• Esperas: las columnas de espera muestran cuánto pasa parado el trabajo. Si el tiempo de ciclo es mucho mayor que el de trabajo activo, el problema está ahí.
• Transporte (traspasos entre equipos que pierden información): un mapa del flujo de valor los saca a la luz.
• Defectos: menos trabajo en vuelo, feedback más corto, errores detectados antes.
• Sobreprocesado (reuniones, documentos o firmas que no aportan): las políticas explícitas permiten cuestionar cada paso.

Bloqueos, dependencias y trabajo que se alarga

Bloqueos

Los hay internos (el equipo puede resolverlos, pero le falta capacidad, conocimiento o una decisión), externos (dependen de un proveedor u otro departamento) y de diseño (la solución no está definida y el elemento vuelve a refinamiento).

Cada tarjeta bloqueada lleva marca visible, fecha de inicio, motivo en una frase y responsable. En la revisión diaria se identifica qué está bloqueado y desde cuándo, se asigna quién lo desbloquea y en qué plazo, y se escala si se pasa del plazo.

El objetivo no es resolverlos todos en la reunión, sino que cada uno tenga dueño y plazo. Los que se repiten apuntan a una causa del sistema: entornos nunca disponibles, dependencias constantes con otro equipo o tarjetas que llegan sin criterios de aceptación.

Dependencias entre equipos

• Visibles: tarjetas vinculadas, carriles por equipo, columnas de espera para lo que aguarda algo externo.
• Coordinadas: sincronización regular entre los equipos implicados, políticas sobre cómo se piden y colas de servicio para las peticiones entre equipos.
• Medidas: tiempo que pasan bloqueadas, frecuencia y antigüedad.
• Reducidas: la mejor gestión es eliminarlas, con equipos organizados en torno a flujos de valor completos, capacidades transversales, arquitectura modular y acuerdos de servicio claros.

Trabajo que se alarga demasiado

El trabajo envejecido (aging WIP) son tarjetas que llevan en curso mucho más de lo habitual. Una referencia es marcar en rojo las que superan el percentil 85 del tiempo de ciclo histórico (ámbar a partir del 50) y tratarlas en la revisión diaria. Suelen esconder bloqueos sin marcar, exceso de WIP, complejidad subestimada o un cambio de prioridad que nadie formalizó.

Ante cada una: buscar la causa real (no "va tarde", sino por qué), decidir (terminarla con más ayuda, dividirla, desbloquearla o cancelarla si ya no aporta valor) y dejarlo por escrito para la retrospectiva. Lo relevante no es que tarde, sino la diferencia sin explicar frente a tarjetas parecidas.

Decidir qué entra: peticiones, opciones reales, coste del retraso y SLA

Aceptar y descartar peticiones

Un backlog que crece sin control no se arregla trabajando más rápido, sino con políticas de entrada escritas: problema claro y para quién, alineación con los objetivos actuales, valor que justifique hacerlo ahora y un tamaño divisible. Para los elementos antiguos sirve una pregunta: "¿Todavía construiríamos esto si lo propusieran hoy?". Si no, se elimina.

En la reunión de reposición se revisa la capacidad, se evalúan las candidatas con esos criterios y se elige con un criterio explícito, por ejemplo el coste del retraso. Hacer visible qué entra y qué espera es lo que permite a los interesados aceptar las prioridades.

Opciones reales y el último momento responsable

Cada elemento del backlog es una opción: el derecho, pero no la obligación, de hacerlo. Conviene decidir en el último momento responsable, cuando no decidir empieza a costar más que decidir con información incompleta; pasado ese punto, la decisión ya se ha tomado por omisión.

En la práctica: priorizar las opciones que caducan antes, descartar las caducadas y recordar que mantener cada opción cuesta. Un backlog sano es pequeño y se poda con regularidad.

Coste del retraso y clases de servicio

El coste del retraso (Cost of Delay, propuesto por Don Reinertsen) es la velocidad a la que un elemento pierde valor mientras no se entrega. No hace falta calcularlo con precisión: estimarlo basta para priorizar mejor que por orden de llegada. Kanban lo traduce en cuatro clases de servicio:

• Urgente (expedite): coste enorme por hora o por día, como una caída del sistema de pagos. Interrumpe el trabajo normal y puede saltarse el límite de WIP.
• Fecha fija: entregar antes no aporta, entregar tarde cuesta mucho (un requisito regulatorio, un lanzamiento con fecha).
• Estándar: coste apreciable sin amenaza grave; la mayor parte del backlog.
• Intangible: poco coste hoy e impacto alto en un momento futuro desconocido, como la deuda técnica.

Un intangible aplazado demasiado acaba siendo urgente. Dedicar toda la capacidad a lo urgente y lo estándar acumula deuda que termina en crisis, así que conviene reservar de forma explícita una parte para los intangibles.

SLA basados en datos, no en promesas

Un SLA en Kanban no promete "lo tendremos en dos semanas": dice, con el histórico del equipo, que "el 85 % de los elementos estándar se terminan en N días o menos". Se calcula con los percentiles del tiempo de ciclo, por tipo de trabajo: el 85 es la referencia habitual y el 95 sirve para compromisos de mucha confianza.

Cada clase tiene el suyo: horas para lo urgente, la fecha externa para lo de fecha fija, flexible para lo intangible.

El SLA se publica junto al tablero y en la revisión del servicio se compara con lo entregado: qué parte lo cumple, si hay señales (como más WIP del habitual) de que va a empeorar y si toca ajustarlo.

Preguntas frecuentes

Formación relacionada en ITNOVE

• Professional Scrum with Kanban (PSK) — Scrum.org · PSK