Scrum vs Kanban: diferencias y cómo elegir
Ambos son marcos ágiles con raíces Lean, pero resuelven problemas distintos: Scrum estructura el TRABAJO EN EQUIPO con roles, eventos y ciclos fijos; Kanban mejora el FLUJO de un proceso existente, sin imponer roles ni cadencia.
No son excluyentes: muchos equipos combinan ambos (a veces llamado "Scrumban") — Sprints de Scrum con tablero y límites de WIP de Kanban. No se trata de elegir el marco "correcto", sino de entender qué problema necesita resolver tu equipo.
| Scrum | Kanban | |
|---|---|---|
| Tipo de trabajo | Proyectos con objetivo definido y Product Backlog que se reduce progresivamente | Servicios continuos o portfolios mixtos, sin punto final claro |
| Roles prescritos | Sí: Product Owner, Scrum Master, Developers | Ninguno — respeta los roles y la organización existente |
| Composición del equipo | Equipos dedicados, multifuncionales y autogestionados | Admite recursos compartidos, especialistas o dependencias jerárquicas |
| Cadencia | Sprints de duración fija (time-boxed) | Flujo continuo — cada reunión tiene su propia frecuencia según demanda |
| Estimación | Necesaria para planificar cada Sprint | Opcional — las métricas de flujo (lead time, throughput) predicen entregas sin estimar |
| Tamaño de los ítems | Deben caber en un Sprint (ítems pequeños) | Acepta tamaño variable, aunque reducirlo mejora el flujo |
| Gestión del cambio | Restringido durante el Sprint | Permitido en cualquier momento vía políticas de priorización explícitas |
| Frecuencia de entrega | Por lotes, al cierre de cada Sprint | Continua — cada ítem se entrega en cuanto está listo |
| Métrica principal | Velocidad (Story Points por Sprint) | Tiempo de ciclo y throughput |
| Cómo limita el trabajo | Por Sprint (cantidad de trabajo aceptada en el Sprint Backlog) | Por columna del tablero (límites de WIP explícitos) |
| Mejor encaje típico | Equipos de producto con entregas por iteración | Soporte, operaciones, flujo de trabajo variable e impredecible |
¿Cuál elegir?
Elige Scrum si tu trabajo se planifica bien en ciclos e implica construir un producto de forma incremental con un Product Owner que prioriza.
Elige Kanban si el trabajo llega de forma impredecible (soporte, incidencias, peticiones ad hoc) y forzar Sprints artificiales no aportaría valor real.
Scrum pide más transformación inicial y ofrece más estructura desde el primer día. Kanban permite una adopción incremental partiendo de donde está el equipo hoy, sin reestructurar nada por adelantado.
Preguntas frecuentes
¿Se pueden combinar Scrum y Kanban?
Sí — es habitual usar el tablero y los límites de WIP de Kanban DENTRO de los Sprints de Scrum, para mejorar el flujo sin renunciar a la estructura de roles y eventos.
¿Qué es Scrumban?
El nombre habitual para esa combinación: Sprints con cadencia y revisabilidad de Scrum, más límites de WIP y métricas de flujo de Kanban para gestionar el trabajo continuo que aparece entre planificaciones.
¿Cuál es "más ágil" de los dos?
Ninguno lo es más por definición — ambos son marcos ágiles válidos. La pregunta correcta es cuál encaja mejor con el TIPO de trabajo de tu equipo, no cuál es superior en abstracto.
¿Kanban tiene certificación oficial como Scrum?
Sí, Scrum.org ofrece Professional Scrum with Kanban (PSK), que enseña a aplicar prácticas Kanban DENTRO de un marco Scrum ya existente.