Gestión de proyectos
Scrum vs Kanban: diferencias reales y cuál elegir
En una línea: Scrum organiza el trabajo en ciclos fijos (sprints) con roles y reuniones definidas, pensado para equipos que planifican qué van a entregar cada 2-4 semanas. Kanban organiza el trabajo como un flujo continuo con límites de tareas en curso, pensado para equipos que reciben trabajo de forma impredecible (soporte, operaciones, mantenimiento). No son enemigos ni sucesores uno del otro — resuelven problemas distintos, y muchos equipos terminan usando un híbrido.
Qué es Scrum, en corto
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.
Qué es Kanban, en corto
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.
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.
Comparativa lado a lado
| Scrum | Kanban | |
|---|---|---|
| Ritmo | Ciclos fijos (sprints) | Flujo continuo |
| Roles | Product Owner, Scrum Master, equipo | Ninguno obligatorio |
| Cambios a mitad de ciclo | Se evitan hasta el próximo sprint | Se aceptan en cualquier momento |
| Métrica clave | Velocidad por sprint | Tiempo de ciclo (cycle time) |
| Mejor para | Trabajo planificable en bloques de 2-4 semanas | Trabajo impredecible o continuo |
Cuál elegir según tu situación
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?
- Elegí 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.
- Elegí 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é.
Preguntas frecuentes
- ¿Se pueden combinar Scrum y Kanban?
- Sí — el híbrido más común (Scrumban) usa sprints de duración fija sin los roles formales de Scrum, o un tablero Kanban con límites WIP más una retrospectiva periódica. Funciona bien en equipos chicos que quieren algo de ritmo sin el overhead completo.
- ¿Kanban sirve para proyectos con fecha de entrega fija?
- Puede, pero pierde la ventaja de reportar avance por ciclos que sí ofrece Scrum. Para proyectos con fecha dura y alcance conocido de antemano, Scrum (o incluso un enfoque en cascada) suele dar mejor visibilidad del progreso.
- ¿Qué es el 'límite WIP' y por qué es la regla central de Kanban?
- WIP (work in progress) es la cantidad de tareas en curso al mismo tiempo. Limitarlo fuerza a terminar tareas antes de empezar nuevas, lo que reduce el multitasking y acorta el tiempo real que tarda cada tarea en completarse.