Scrum vs Kanban: las diferencias y cuál le va a un equipo pequeño
Por Andrei Finogeev, fundador de Weft ·
Scrum planifica el trabajo en sprints fijos de un mes o menos, con tres responsabilidades (Product Owner, Scrum Master, Developers) y cuatro eventos dentro de cada sprint. Kanban no tiene sprints ni roles prescritos: el trabajo fluye de forma continua por un tablero, y el equipo limita explícitamente cuánto hay en curso. Elige Scrum cuando un equipo de varias personas necesita un ritmo de entrega fijo y un objetivo estable en cada ciclo; elige Kanban cuando el trabajo llega de forma impredecible y las prioridades cambian a diario. Scrumban queda en medio: el flujo de Kanban, con sprints solo donde ayudan.
Scrum vs Kanban vs Scrumban: chuleta
Scrum según la Guía de Scrum de 2020; Kanban según la Guía de Kanban (v2025.5). Scrumban no tiene una guía oficial; la columna describe cómo se suele aplicar.
| Scrum | Kanban | Scrumban | |
|---|---|---|---|
| Cadencia | Sprints fijos de un mes o menos, uno tras otro | Flujo continuo, sin iteraciones | Flujo continuo; sprints opcionales, normalmente de una o dos semanas |
| Roles | Product Owner, Scrum Master, Developers | Ninguno prescrito | Ninguno prescrito; a menudo una persona se encarga de las prioridades |
| Reuniones | Sprint Planning, Daily Scrum (15 min), Sprint Review, Sprint Retrospective | Ninguna prescrita | Solo las que el equipo considera útiles, normalmente una planificación y una revisión |
| Qué limita el trabajo | Lo que el equipo asume para el sprint | Un límite explícito al trabajo en curso | Un límite al trabajo en curso, más el objetivo del sprint si lo hay |
| Cambiar el alcance a mitad de ciclo | El Objetivo del Sprint no cambia; el Sprint Backlog se puede refinar | En cualquier momento: el siguiente elemento se tira cuando hay hueco | En cualquier momento; el objetivo del sprint es una meta, no un candado |
| Métricas principales | Avance hacia el Objetivo del Sprint y el Objetivo del Producto | Trabajo en curso, throughput, antigüedad de los elementos, cycle time | Normalmente las métricas de flujo de Kanban |
| Tablero | Opcional; se reinicia cada sprint | El núcleo del método; permanente | Permanente; un sprint es una porción de él |
| Encaja mejor con | Equipos de producto de hasta unas diez personas que trabajan hacia un objetivo | Soporte, operaciones y cualquiera cuyo trabajo llega sin planificar | Equipos pequeños y fundadores en solitario que quieren flujo y un objetivo a corto plazo |
Qué es Scrum
Ken Schwaber y Jeff Sutherland presentaron Scrum por primera vez en la conferencia OOPSLA de 1995; las reglas actuales son las de la Guía de Scrum de 2020. Un Scrum Team suele tener diez personas o menos, y trabaja en sprints: eventos de duración fija de un mes o menos que empiezan justo cuando termina el anterior.
Cada sprint tiene cuatro eventos. La Sprint Planning (como máximo ocho horas para un sprint de un mes) fija el Objetivo del Sprint y elige el trabajo. La Daily Scrum es una revisión de 15 minutos para los Developers. La Sprint Review (como máximo cuatro horas) muestra el resultado a los interesados, y la Sprint Retrospective (como máximo tres horas) analiza cómo ha trabajado el equipo.
Scrum tiene tres artefactos, cada uno con un compromiso: el Product Backlog (el Objetivo del Producto), el Sprint Backlog (el Objetivo del Sprint) y el Incremento (la Definición de Terminado).
Qué es Kanban
La Guía de Kanban define Kanban como "una estrategia para optimizar el flujo de valor a través de un proceso". Procede del sistema de tarjetas que Toyota usaba para indicar cuándo producir más, y se adaptó al trabajo del conocimiento en la década de 2000.
Tiene tres prácticas: definir y visualizar el flujo de trabajo, gestionar activamente los elementos que hay en él y mejorarlo. La única regla estricta es que las personas del sistema controlan explícitamente cuántos elementos hay en curso entre el inicio y el final: el límite de trabajo en curso (WIP).
Kanban no prescribe roles, sprints ni reuniones. Mide cuatro métricas de flujo: trabajo en curso, throughput, antigüedad de los elementos y cycle time.
Pros y contras
Scrum
- Un ritmo fijo: todo el mundo sabe cuándo toca el siguiente resultado
- Un objetivo claro por sprint evita que el equipo se disperse
- Momentos integrados para inspeccionar el producto y el proceso
- Cuatro eventos por sprint son un coste de tiempo real para un equipo de dos o tres personas
- El trabajo urgente o espera al siguiente sprint o rompe el plan
- Hace falta alguien en cada responsabilidad, y un fundador solo no puede repartirlas
Kanban
- Arranca en el tablero que ya tienes; solo hay que añadir un límite de WIP
- Se puede incorporar trabajo nuevo en cualquier momento
- Las métricas de flujo muestran dónde se atasca el trabajo
- No trae fecha límite ni objetivo, así que el trabajo largo puede alargarse sin rumbo
- Sin límite de WIP no es más que una lista de tareas con columnas
- La planificación a futuro queda por completo en manos del equipo
Cuál elegir
- Un equipo de producto de cinco a diez personas con un roadmap estable
- Scrum. Los eventos compensan cuando varias personas tienen que ponerse de acuerdo en un objetivo cada par de semanas.
- Soporte, operaciones o un equipo que vive de las peticiones entrantes
- Kanban. El trabajo llega cuando llega; un límite de WIP y una columna Done clara importan más que un plan de sprint.
- Un fundador en solitario o un equipo de dos a cinco personas
- Scrumban. Mantén un tablero continuo con límite de WIP y usa un sprint de una o dos semanas como objetivo a corto plazo, sin el conjunto completo de eventos de Scrum.
Scrumban: el término medio
Corey Ladas describió Scrumban como una forma de que los equipos Scrum avanzaran hacia un flujo de tipo pull. En la práctica es un tablero Kanban con límites de WIP que nunca se reinicia, más sprints como time-boxes opcionales que agrupan parte del trabajo. Nuestra guía completa explica las reglas y cómo montar el tablero: ¿Qué es Scrumban?
Cuando agentes de IA hacen parte del trabajo
Si ChatGPT, Claude, Cursor o Codex cogen tareas por ti, los eventos de Scrum se quedan sin asistentes: un agente no va a la daily. Lo que sigue importando es lo que aporta Kanban: un tablero que muestra qué está en curso, un límite de WIP para que no se empiecen diez tareas a la vez y una regla clara de cuándo una tarjeta está terminada.
El cuello de botella también se desplaza. Los agentes terminan rápido, y el paso lento pasa a ser tu revisión de lo que han hecho. Un límite a cuánto trabajo terminado puede quedar esperándote es un límite de WIP en la columna humana.
Weft es un tablero Scrumban hecho para esto: columnas, sprints opcionales, un límite a cuánto trabajo terminado puede esperar tu revisión y una IA que reclama una tarea antes de empezar, informa del progreso y se detiene a preguntarte cuando solo tú puedes decidir.
Preguntas
¿Scrum y Kanban son lo mismo?
No. Los dos son enfoques ágiles y los dos suelen usar un tablero, pero Scrum planifica el trabajo en sprints fijos con roles y eventos definidos, mientras que Kanban tiene flujo continuo, ningún rol prescrito y un límite explícito al trabajo en curso.
¿Se hacen sprints en Kanban?
No en Kanban propiamente dicho: la Guía de Kanban no prescribe iteraciones. Los equipos que añaden sprints a un tablero Kanban suelen estar haciendo Scrumban.
¿Cómo funciona un sprint de Scrum?
Un sprint es un periodo fijo de un mes o menos. Empieza con la Sprint Planning, que fija el Objetivo del Sprint; los Developers se reúnen en una Daily Scrum de 15 minutos; termina con una Sprint Review del resultado y una Sprint Retrospective sobre el proceso, y el siguiente sprint empieza de inmediato.
¿Quién inventó Scrumban?
El término se atribuye a Corey Ladas, que describió Scrumban en varios ensayos y en un libro de 2009 como una forma de que los equipos Scrum avanzaran hacia el pull al estilo Kanban.
¿Scrum es lo mismo que Agile?
No. Agile es el conjunto de valores y principios del Manifiesto Ágil de 2001; Scrum y Kanban son dos formas concretas de trabajar que los siguen.
¿Puede un desarrollador en solitario usar Scrum?
No tal como está escrito: Scrum da por hecho un equipo con tres responsabilidades separadas. Un desarrollador en solitario suele quedarse con las partes que le ayudan, un backlog y un objetivo de sprint corto, y lleva el tablero como Kanban, que es justamente Scrumban.
Fuentes
Consultado el 11 de noviembre de 2026.