Kanban vs Scrum: diferencias reales y cuál elegir

Scrum divide el trabajo en sprints — ciclos de duración fija, típicamente 2 semanas — con tres roles (Product Owner, Scrum Master, equipo de desarrollo) y un ritual fijo: planificación al inicio del sprint, daily standup cada día, revisión y retrospectiva al final. El equipo se compromete a un conjunto cerrado de tareas al empezar el sprint y no lo modifica a mitad de camino salvo excepción.

El valor central de Scrum es la previsibilidad del ciclo: al final de cada sprint hay una demo con algo funcionando, y el equipo puede medir su velocidad (cuánto trabajo completa por sprint) para planificar mejor los siguientes.

Kanban no tiene ciclos ni roles fijos. El trabajo fluye por columnas (típicamente Por hacer → En curso → Hecho) y la única regla dura es el límite de trabajo en curso (WIP): un máximo de tareas permitidas en cada columna intermedia. Cuando una columna llega a su límite, nadie puede tomar una tarea nueva hasta que termine y saque una de las que ya están en curso — esto fuerza a terminar antes de empezar más. Cómo fijar ese número está en Kanban en la práctica: límites WIP.

No hay sprints ni compromiso cerrado: las tareas entran y salen del tablero de forma continua, según la prioridad del momento. Es el sistema natural para equipos cuyo trabajo llega de forma impredecible — soporte técnico, operaciones, un equipo de diseño que atiende pedidos de varias áreas.

La pregunta que decide no es "¿cuál es mejor?" sino: ¿el trabajo que recibe mi equipo llega en lotes planificables, o llega de forma impredecible?

• Elige Scrum si tu equipo construye producto o software con un backlog priorizable, y te beneficia mostrar avances cada 2-4 semanas a stakeholders — la cadencia fija ordena el trabajo y facilita reportar progreso.
• Elige Kanban si tu equipo hace soporte, operaciones, o recibe pedidos de múltiples áreas sin poder planificarlos con semanas de anticipación — forzar un sprint sobre trabajo que llega al azar solo genera reordenar tareas constantemente.
• Un híbrido (a veces llamado Scrumban) — sprints con duración fija pero sin roles formales, o Kanban con una revisión periódica tipo retrospectiva — funciona bien para equipos chicos que quieren algo de estructura sin el overhead completo de Scrum.

Ninguno de los dos resuelve, por sí solo, un alcance mal definido o estimaciones optimistas — esos problemas son anteriores a la metodología. Ver las 5 fases de un proyecto y la matriz RACI para la parte que ninguna metodología ágil reemplaza: quién decide qué.