Kanban vs Scrum: cuándo elegir cada uno (y cuándo el híbrido es mejor)
Kanban y Scrum son los dos métodos ágiles más usados, pero confundirlos es lo que hace que la mayoría de los equipos elijan mal. La decisión correcta no depende de cuál es "mejor" en abstracto, sino del tipo de trabajo, el ritmo de cambios y el tamaño de tu equipo.
Esta guía resuelve la elección en una página. Encontrarás respuesta en 30 segundos, quiz de 3 preguntas, tabla comparativa con 12 dimensiones, ejemplos reales LATAM y una sección que casi nadie escribe: cuándo no necesitas ninguno.
La respuesta en 30 segundos
Scrum si tu trabajo tiene scope fijo, fechas de entrega claras y un cliente o stakeholder disponible cada dos semanas. Kanban si el trabajo entra de forma impredecible, atiendes a varios clientes en paralelo o necesitas entregar de forma continua. Scrumban (el híbrido) si tu equipo combina los dos tipos de trabajo en el mismo período.
La pregunta correcta no es "¿cuál es mejor?" sino "¿cuál encaja con cómo entra el trabajo a mi equipo?".
Cualquier método, un solo workspace.
Rock combina tablero Kanban, sprints, chat y notas en el mismo espacio. Cambia de método sin migrar herramienta.
Encuentra tu método en 3 preguntas
Responde estas tres preguntas y te decimos cuál método encaja mejor con tu equipo. Sin debate filosófico, sin gradientes: recomendación clara basada en cómo entra tu trabajo.
¿Scrum o Kanban para tu equipo?
Tres preguntas. Una recomendación.
1. ¿Cómo entra el trabajo a tu equipo?
2. ¿Qué tan disponible está tu cliente o stakeholder?
3. ¿Cómo es tu equipo?
Kanban en una frase
Kanban es un método visual de gestión del trabajo. El equipo mueve tarjetas por un tablero de columnas (Por hacer → En curso → Revisión → Terminado) y pone un límite a cuántas tareas pueden estar al mismo tiempo en cada columna. No hay sprints, no hay roles formales, no hay ceremonias obligatorias. La regla central: nadie empieza algo nuevo si su columna ya está en su límite WIP.
Nació en Toyota en los años 50 y David Anderson lo adaptó al software en 2007. Hoy se usa en equipos de soporte, marketing, contenido, ops y cualquier flujo de trabajo continuo. Profundiza en qué es Kanban si quieres ver los principios y el tablero al detalle.
Scrum en una frase
Scrum es un marco ágil con cadencia fija. El equipo planifica un sprint (típicamente 2 semanas) y se compromete a entregar un incremento al final de ese ciclo. Tres roles sostienen el marco: Product Owner (qué se construye), Scrum Master (que el método se respete) y Equipo de Desarrollo (cómo se construye). Cada sprint cierra con una review con el cliente y una retrospectiva con el equipo.
Jeff Sutherland y Ken Schwaber lo formalizaron en 1995 para equipos de software. Hoy se aplica también en marketing, RR.HH., operaciones y cualquier equipo que entrega productos por ciclos. La referencia canónica es el Scrum Guide 2020, gratis en scrumguides.org.
Tabla comparativa completa
Doce dimensiones, lado a lado. Las primeras 7 son la mesa puesta que cualquier comparativa cubre; las últimas 5 son las que la mayoría de los artículos saltan.
| Dimensión | Kanban | Scrum |
|---|---|---|
| Cadencia | Flujo continuo, sin sprints | Sprints fijos de 1 a 4 semanas |
| Roles | Ninguno obligatorio | Product Owner, Scrum Master, Equipo |
| Eventos / ceremonias | Ninguno obligatorio (reuniones optativas) | Sprint Planning, Daily, Review, Retro |
| Filosofía ante el cambio | Se aceptan cambios en cualquier momento | El sprint se cierra al cambio una vez iniciado |
| Métricas clave | Cycle time, throughput, WIP | Velocity, burndown del sprint |
| Tablero | Columnas + tarjetas + límites WIP | Tablero de sprint con columnas básicas |
| Mejor para | Soporte, marketing, ops, retainers | Producto con scope fijo, lanzamientos |
| Artefactos | Tablero + políticas explícitas | Product Backlog, Sprint Backlog, Incremento |
| Estimación | Opcional (cycle time real) | Story points o T-shirt sizing |
| Curva de aprendizaje | Baja (días) | Media (semanas) |
| Overhead semanal en ceremonias | 0-1 hora | 3-5 horas por persona |
| Reversibilidad | Alta (puedes parar mañana) | Media (necesitas cerrar el sprint en curso) |
Cuándo elegir Scrum
Scrum funciona mejor cuando se cumplen tres condiciones al mismo tiempo. Primera: el trabajo tiene un alcance que se puede planificar dos semanas adelante. Segunda: hay alguien que toma decisiones de producto y está disponible para revisar el avance. Tercera: el equipo es dedicado, no compartido entre varios clientes o proyectos.
Si una de esas tres falla, Scrum agrega overhead sin proporcionarte el beneficio. Si las tres fallan, vas a estar pagando ceremonias caras a cambio de cero ritmo predecible.
Ejemplo real: startup B2B SaaS en Bogotá. Equipo de 6 ingenieros lanzando la v1.0 de su producto. Deadline contractual con un cliente piloto en 3 meses. El CTO actúa como Product Owner. Sprints de 2 semanas, review con el cliente piloto cada 14 días, retrospectiva interna los viernes alternos. Scrum les da algo que Kanban no podría: una promesa creíble de qué van a tener listo el día del lanzamiento. Y el ritmo del cliente piloto en las reviews crea presión sana de entrega.
Cuándo elegir Kanban
Kanban funciona mejor cuando el trabajo entra de forma impredecible o cuando tu equipo atiende a varios clientes o proyectos en paralelo. La promesa no es entregar X cosas en Y semanas; es entregar lo que sea que esté en curso lo más rápido y predeciblemente posible.
Si tu trabajo es 80% reactivo (soporte, requests de cliente, bugs urgentes), Scrum no encaja: para cuando termina el sprint planning, ya cambió el contexto. Kanban absorbe ese tipo de entrada sin fricción.
Ejemplo real: agencia de marketing en CDMX. Equipo de 8 personas manejando 12 cuentas en retainer. Cada cliente pide cosas distintas a ritmos distintos. Algunos días son 3 piezas para 3 clientes diferentes; otros, 1 campaña grande para un solo cliente. Adoptaron un tablero Kanban con un swimlane por cliente y un límite WIP de 5 en "En producción". Resultado a los dos meses: el cycle time promedio de una pieza bajó de 9 días a 4. No porque trabajaran más, sino porque dejaron de empezar 12 cosas al mismo tiempo.
Lo que vemos en equipos LATAM.
Equipos product-led suelen empezar con Scrum y bajar a Kanban después del MVP. Agencias suelen ir directo a Kanban. Decidir es más fácil cuando los dos métodos viven en el mismo workspace.
Scrumban: cuándo el híbrido es mejor
Scrumban no es un compromiso entre los dos métodos; es un tercer método legítimo con su propio caso de uso. Funciona así: mantienes los sprints de Scrum (planificación, daily, review, retro) pero sumas el tablero visual y los límites WIP de Kanban. Resultado: ritmo predecible de Scrum + flexibilidad operativa de Kanban.
El caso típico donde tiene sentido es un equipo que combina trabajo de scope fijo y trabajo continuo en el mismo período. No es raro en producto: el equipo de ingeniería en una startup tiene que entregar features nuevas (Scrum) mientras atiende bugs y pedidos de soporte (Kanban). Forzar todo a Scrum hace que los bugs esperen al próximo sprint. Forzar todo a Kanban quita la cadencia que el equipo necesita para alinear con el resto de la empresa.
Ejemplo real: equipo product-led de 5 personas en una fintech argentina. Tres ingenieros + un diseñador + un PM. Combinan sprints de 2 semanas para roadmap de producto con un swimlane de "Soporte y bugs urgentes" que corre Kanban con WIP de 2. El daily cubre ambos lados; la retrospectiva pregunta dónde se atascaron las dos disciplinas. A los seis meses, el equipo reportó que dejaron de "elegir" entre roadmap y bugs todas las semanas; el modelo lo hace por ellos.
Si tu equipo se siente atrapado entre los dos métodos, Scrumban es probablemente lo que necesitas. Empieza por adoptar Scrum y agregar el WIP limit cuando notes que los bugs siempre quedan al final del sprint.
Cuándo no necesitas ninguno
Esta es la sección que casi nadie escribe pero que más gente necesita leer. Si tu equipo tiene 1 a 3 personas y todavía estás validando qué problema resolver, probablemente no necesitas Kanban ni Scrum ni Scrumban. Necesitas tomar nota de qué hacer mañana y empezar.
Frameworks ágiles agregan valor cuando hay suficiente trabajo recurrente o suficiente gente para que la coordinación se vuelva un problema. Antes de ese umbral, son overhead disfrazado de profesionalismo.
Señales de que estás en este caso:
- Eres freelance solo o equipo de 2-3 personas que se ve todos los días
- El trabajo de esta semana no se parece al de la anterior
- Tu cliente eres tú mismo (proyecto personal, fundador validando una idea)
- Tienes menos de 6 meses con el proyecto en marcha
Si te ves ahí, adopta una lista de tareas con prioridades (cualquier app o cuaderno sirve) y vuelve a leer este artículo cuando crezcas. Decidir no usar Kanban ni Scrum es una decisión válida, no un fracaso.
Errores comunes al elegir
Después de mirar cientos de equipos adoptar uno u otro, estos son los cinco errores que más matan la decisión en los primeros tres meses:
- Copiar al equipo vecino El equipo de ingeniería usa Scrum, así que el equipo de marketing también debería. No. Cada equipo tiene un tipo de trabajo distinto y la elección debería basarse en eso, no en lo que hace la otra área. El equipo de soporte no necesita sprints; el equipo de producto sí.
- Tratar Scrum o Kanban como religión Algunos consultores y certificadores defienden la pureza del método como si fuera teología. Es ingeniería de procesos, no doctrina. Si una práctica de Scrum no aporta a tu equipo después de 3 sprints, sácala. Si tu Kanban necesita una review semanal con el cliente, agrégala.
- Cambiar de método antes de 2 sprints El primer sprint siempre se siente caótico. El segundo todavía está calibrando. Recién en el tercero ves si el método encaja con tu equipo. Cambiar antes es decidir con ruido, no con señal.
- Ignorar el overhead en horas Scrum cuesta 3-5 horas por persona por semana en ceremonias. Para un equipo de 6 son 18-30 horas semanales que no se invierten en construir. Si tu producto tiene urgencia y el equipo es chico, el costo puede ser mayor al beneficio. Haz los números antes de adoptar.
- No medir nada Adoptar Kanban sin medir cycle time, o Scrum sin medir velocity, te deja sin datos para evaluar si el método funciona. Anota 4-5 cosas por sprint o por mes (tarjetas terminadas, días promedio en curso, blockers reportados) y revisa los datos cada 6 semanas.
Preguntas frecuentes
¿Qué es mejor, Kanban o Scrum?
Ninguno es "mejor" en abstracto. Scrum funciona mejor para trabajo con scope fijo y deadline; Kanban para flujo continuo e impredecible. Si tu equipo combina los dos, Scrumban es la respuesta correcta.
¿Cuál es la diferencia principal entre Kanban y Scrum?
La cadencia. Scrum trabaja en sprints fijos con planificación al inicio y entrega al final; Kanban es flujo continuo, sin sprints. Todo lo demás (roles, ceremonias, artefactos) deriva de esa diferencia.
¿Qué tienen en común Kanban y Scrum?
Los dos son métodos ágiles, los dos usan tableros visuales, los dos priorizan entregas incrementales y los dos parten del manifiesto ágil. Donde divergen es en el cómo: ritmo, roles y artefactos.
¿Cuándo usar Kanban en lugar de Scrum?
Cuando el trabajo entra de forma impredecible, cuando tu equipo atiende a varios clientes o proyectos en paralelo, o cuando no puedes permitirte el overhead de ceremonias semanales. Soporte, marketing, ops y retainers de agencia suelen funcionar mejor con Kanban.
¿Se pueden usar Kanban y Scrum juntos?
Sí. La combinación se llama Scrumban y es legítima, no un compromiso. Mantienes la cadencia de Scrum y agregas el tablero visual y los límites WIP de Kanban. Funciona bien cuando combinas trabajo de scope fijo con trabajo continuo.
¿Cuál es más fácil de implementar?
Kanban. Lo arrancas en una tarde con un tablero, un par de columnas y un límite WIP. Scrum requiere definir tres roles, agendar cuatro tipos de eventos y educar al equipo en el marco, lo que toma 2-3 semanas hasta sentirse natural.
¿Qué método es mejor para equipos pequeños?
Equipos de 4 personas o menos suelen funcionar mejor con Kanban. El overhead de las ceremonias de Scrum no compensa cuando el equipo se ve todos los días. A partir de 5-6 personas con trabajo de scope fijo, Scrum empieza a justificar su costo.
¿Kanban es una metodología ágil?
Sí. Aunque nació en Toyota antes del manifiesto ágil de 2001, sus principios (visibilidad, flujo, mejora continua, respuesta al cambio) son perfectamente alineados con la filosofía ágil. Es ágil sin sprints.
