Scrum, Kanban y cascada no compiten por ser «la mejor metodología»: cada uno resuelve un problema distinto. La cascada sirve cuando sabes qué hay que construir y cambiar a mitad sale caro. Scrum, cuando el producto se descubre construyéndolo. Kanban, cuando el trabajo llega sin parar y lo que necesitas es que fluya sin atascos.
La elección, por tanto, no empieza por el método sino por tu proyecto: cuánto sabes de lo que vas a entregar, cada cuánto llega trabajo nuevo y qué cuesta equivocarse. Con esas tres respuestas, muchas veces la decisión sale sola, antes de abrir ninguna herramienta.
En pocas palabras | Cascada | Scrum | Kanban |
|---|---|---|---|
Qué problema resuelve | Proyectos con requisitos estables y cambios caros | Productos complejos que se descubren por el camino | Trabajo que entra de forma continua |
Cómo avanza | Por fases, una detrás de otra | En sprints de un mes o menos | En flujo continuo, sin ciclos fijos |
Qué controla | El plan y el cumplimiento de cada fase | El objetivo de cada sprint | El trabajo en curso (WIP) |
Cuándo ves resultados | Al final, en las pruebas y la entrega | Al final de cada sprint | Cada vez que termina un elemento |
Qué problema resuelve cada uno
Cada forma de trabajo nace de un problema concreto. La cascada intenta reducir el riesgo de un proyecto grande planificándolo por fases antes de construir. Scrum ataca la incertidumbre: entregar algo útil en ciclos cortos para aprender rápido. Kanban se ocupa del atasco: limitar el trabajo abierto para que lo empezado se termine antes.
Si lo traduces a preguntas, queda así:
¿Sabes ya qué hay que entregar y cambiarlo después sería caro? Ese es el terreno de la cascada: una instalación, una migración con fecha cerrada, un proyecto con un contrato que fija el alcance.
¿Sabes hacia dónde vas, pero no exactamente qué construir? Ahí encaja Scrum: un producto digital nuevo, un servicio que se ajusta con lo que dicen los usuarios.
¿El trabajo te llega en forma de peticiones que no paran? Eso pide Kanban: soporte, mantenimiento, un equipo de contenidos, operaciones.
Las tres son formas de gestionar proyectos que conviven en la misma empresa. Es normal que el departamento de sistemas trabaje con Kanban, el equipo de producto con Scrum y la obra de la nueva oficina con un plan en cascada. Lo raro sería obligar a todos a usar la misma.
La metodología cascada y lo que de verdad escribió Royce en 1970
La metodología cascada organiza un proyecto en fases secuenciales: requisitos, análisis, diseño, desarrollo, pruebas y operación. Cada fase parte del resultado de la anterior. Su origen se atribuye a un artículo de Winston W. Royce de 1970, aunque Royce describió ese esquema para señalar sus riesgos, no para recomendarlo tal cual.
El texto es «Managing the Development of Large Software Systems», presentado en el congreso IEEE WESCON de agosto de 1970. Royce dibuja una secuencia para programas grandes: dos niveles de requisitos (del sistema y del software), análisis, diseño del programa, codificación, pruebas y operación. Es el famoso gráfico de escalones que hoy llamamos cascada. Y justo debajo escribe: «I believe in this concept, but the implementation described above is risky and invites failure» («creo en el concepto, pero la implementación descrita es arriesgada y provoca fracasos»).
El motivo que da es muy práctico. Las pruebas llegan al final y son el primer momento en que el sistema se comprueba de verdad. Si ahí aparece un problema serio, toca rediseñar y, según Royce, el proyecto vuelve al origen con retrasos o sobrecostes de hasta el 100 %. Por eso propone cinco correcciones:
Hacer un diseño preliminar del programa antes del análisis.
Documentar el diseño a fondo.
«Do it twice»: construir primero una versión piloto a pequeña escala.
Planificar, controlar y supervisar las pruebas.
Implicar al cliente de manera formal en varios momentos, no solo al principio y al final.
Dos detalles más que se suelen contar mal. Royce admite iteración entre fases contiguas («there is an iteration with the preceding and succeeding steps») y en todo el artículo no aparece la palabra waterfall. La cascada «pura», sin vuelta atrás ni cliente a mitad de camino, es una simplificación posterior de su esquema.
Leído hoy, Royce sigue dando un buen criterio: la cascada funciona cuando el riesgo de descubrir problemas tarde es bajo, o cuando lo reduces con prototipos y revisiones con el cliente. Si quieres ver cómo se pasó de este enfoque al ágil, lo contamos en la guía para implementar metodologías ágiles.
Qué es Scrum según la Guía Scrum 2020
Scrum es, según su guía oficial, «un marco ligero que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptables para problemas complejos». Trabaja en sprints de un mes o menos, con un equipo pequeño que entrega un incremento útil en cada ciclo y revisa el rumbo antes del siguiente.
La referencia es la Guía Scrum 2020 de Ken Schwaber y Jeff Sutherland, en su traducción oficial al español de España. Lo esencial cabe en pocas piezas:
Equipo. Un Scrum Master, un Product Owner y los desarrolladores, «por lo general 10 o menos personas». La guía insiste en que «no hay sub-equipos ni jerarquías». Si te interesa el papel de quien decide qué se construye, tienes el detalle en qué hace un Product Owner.
Sprint. Son «eventos de longitud fija de un mes o menos». Durante el sprint «no se hacen cambios que pongan en peligro el Objetivo Sprint», aunque el alcance se puede clarificar con el Product Owner.
Eventos. Planificación del sprint (máximo ocho horas para un sprint de un mes), Daily Scrum de 15 minutos como máximo, revisión del sprint (hasta cuatro horas) y retrospectiva (hasta tres).
Artefactos. Product Backlog, Sprint Backlog e Incremento, cada uno con su compromiso: Objetivo del Producto, Objetivo del Sprint y Definición de Hecho.
La idea de fondo está en una frase de la guía: Scrum «emplea un enfoque iterativo e incremental para optimizar la previsibilidad y controlar el riesgo». Leída junto a Royce, se parece bastante a su «hazlo dos veces» llevado al extremo: en lugar de un piloto, un incremento usable cada pocas semanas.
Un apunte que confunde a muchos: la Guía Scrum no habla de project manager. Cómo encajan los roles de gestión alrededor de un equipo Scrum lo explicamos en agile coach vs project manager.
Qué es Kanban según The Kanban Guide
The Kanban Guide de ProKanban.org (edición de 2025) define Kanban como una estrategia para optimizar el flujo de valor a través de un proceso. No impone ciclos ni roles: se basa en tres prácticas, que son definir y visualizar el flujo de trabajo, gestionar activamente los elementos en curso y mejorar ese flujo de forma continua.
Hay dos guías de referencia y conviene decir cuál usas. Aquí seguimos The Kanban Guide de ProKanban.org, edición de 2025 con licencia CC BY-SA 4.0. Sus piezas principales son:
Definición del flujo de trabajo (DoW). Qué es un elemento de trabajo, cuándo empieza y cuándo termina, por qué estados pasa y con qué políticas.
Control del trabajo en curso (WIP). Todo lo que está empezado y no terminado. Limitarlo es la palanca principal.
Expectativa de nivel de servicio (SLE). Una previsión con plazo y probabilidad, del tipo «el 85 % de los elementos se terminan en ocho días o menos», calculada con los tiempos reales del equipo.
Cuatro métricas obligatorias. WIP, rendimiento (throughput, elementos terminados por unidad de tiempo), edad de cada elemento y tiempo de ciclo.
La otra referencia es la guía del Método Kanban de Kanban University, basada en el libro de David J. Anderson de 2010. Aporta una idea útil para este artículo: Kanban no es una metodología ni un marco, sino un método que se aplica sobre la forma de trabajar que ya tienes. Por eso, dice, no se trata de usar Kanban «en lugar de» otra metodología, sino de añadirlo.
Si buscas el paso a paso para montar un tablero, principios, límites WIP y herramientas, lo tienes en nuestra guía de la metodología Kanban. Aquí nos quedamos con la comparación.
Diferencias entre Scrum y Kanban
La diferencia principal entre Scrum y Kanban es cómo organizan el tiempo. Scrum trabaja en sprints de duración fija, con un objetivo y unos eventos definidos. Kanban trabaja en flujo continuo: el equipo empieza un elemento nuevo cuando hay capacidad libre, sin esperar a que acabe un ciclo. De ahí salen casi todas las demás diferencias.
Criterio | Scrum | Kanban |
|---|---|---|
Ritmo | Sprints de un mes o menos | Flujo continuo |
Roles | Scrum Master, Product Owner y desarrolladores | La guía no define roles: se mantienen los que hay |
Compromiso | Objetivo del Sprint | Expectativa de nivel de servicio (SLE) |
Cómo se limita el trabajo | Lo que el equipo selecciona para el sprint | Límites de WIP en el flujo |
Trabajo nuevo | Se planifica para el siguiente sprint, sin cambios que pongan en peligro el Objetivo Sprint | Entra cuando hay capacidad libre (sistema pull) |
Reuniones | Cuatro eventos con duración máxima | Ninguna obligatoria; las revisiones del flujo se hacen cuando el contexto lo pide |
Métricas | Las que el equipo elija para ver el progreso hacia los objetivos | WIP, rendimiento, edad de cada elemento y tiempo de ciclo |
En la práctica, muchos equipos los combinan. La guía de ProKanban lo admite de forma expresa: dice que se pueden y probablemente se deben añadir otros principios y metodologías al sistema Kanban, siempre que se mantengan sus prácticas y métricas mínimas. Un equipo Scrum que visualiza su sprint en un tablero y limita el trabajo en curso está usando las dos cosas a la vez, y suele funcionar bien.
Mi criterio para equipos que dudan es sencillo. Si cada semana te entran urgencias que no pueden esperar a la siguiente planificación, empieza por Kanban. Si el trabajo se puede planificar en bloques y necesitas enseñar algo terminado con regularidad, empieza por Scrum. Lo que no recomiendo es copiar los eventos de Scrum sin entregar incrementos: tendrás las reuniones y ninguna de las ventajas.
Combinar métodos con criterio, y saber cuándo conviene cada uno, es lo que se trabaja en el Máster en Project Management de ThePower, que dedica su módulo 3 a las «Metodologías de gestión de proyectos» y el módulo 4 a las «Metodologías Agile by Project Management Institute (PMI)».
Metodologías de gestión de proyectos · Metodologías Agile by PMI
Descarga el dossier del Máster en Project Management y consulta sus módulos, con 36 PDUs oficiales del PMI obtenidos automáticamente al completar los módulos.
Cuándo usar cada uno: cinco criterios para elegir
Para elegir entre cascada, Scrum y Kanban, mira cinco cosas: lo estables que son los requisitos, cómo llega el trabajo, cuánto cuesta cambiar, cada cuánto necesitas enseñar resultados y qué exige el contrato o la normativa. Ninguno es mejor en abstracto; cada uno encaja con una combinación de respuestas.
Estabilidad de los requisitos. Si están cerrados y bien entendidos, la cascada te da un plan claro. Si vas a descubrirlos con usuarios, Scrum. Si cada petición es pequeña y tiene sentido por sí sola, Kanban.
Cómo llega el trabajo. En lotes que se pueden planificar, Scrum o cascada. Como un goteo de peticiones con prioridades que cambian, Kanban.
Coste de cambiar. Cuando rehacer algo cuesta mucho (material comprado, obra hecha, integraciones con terceros), la planificación previa compensa. Cuando cambiar es barato, los ciclos cortos ganan.
Frecuencia de entrega. Si el cliente necesita ver avances cada pocas semanas para decidir, Scrum. Si cada elemento tiene valor por sí solo en cuanto se termina, Kanban.
Contrato y normativa. Un alcance cerrado por contrato o un proceso con validaciones formales por fases empuja hacia la cascada, o hacia un enfoque mixto con fases planificadas y desarrollo iterativo dentro.
Un ejemplo ilustrativo (empresa ficticia) ayuda a verlo. Una distribuidora de 120 personas tiene tres frentes a la vez. El cambio de su programa de gestión, con fecha de corte y contrato cerrado con el proveedor, va por fases. La nueva app para sus comerciales, que nadie sabe aún cómo usará, se construye en sprints de dos semanas. Y el equipo de sistemas, que recibe incidencias cada día, trabaja con un tablero Kanban y un límite de cinco tareas abiertas. Tres métodos, una sola empresa y ningún conflicto.
Los errores más frecuentes al aplicar cada método
Los fallos habituales no vienen del método elegido, sino de aplicarlo a medias. Una cascada sin revisiones con el cliente, un Scrum con sprints eternos o un Kanban sin límite de trabajo en curso pierden justo lo que hace útil a cada uno. La buena noticia es que todos se corrigen con pequeños ajustes.
Cascada sin el cliente dentro. Es exactamente lo que Royce desaconsejaba: proponía tres momentos de revisión formal con el cliente después de definir los requisitos. Ponlos en el plan desde el primer día.
Pruebas solo al final. Si puedes, prueba antes una parte crítica en pequeño. Es el «hazlo dos veces» de 1970 y sigue valiendo.
Sprints que se alargan. La Guía Scrum fija un mes como máximo por una razón: cuando el horizonte es demasiado largo, el objetivo puede quedar obsoleto. Si cada sprint se te queda corto, divide el trabajo en piezas más pequeñas.
Daily convertida en reunión de estado. Son 15 minutos para que los desarrolladores revisen el avance hacia el Objetivo Sprint, no para informar al jefe.
Kanban sin límite de WIP. Sin límites, un tablero es una lista de tareas bonita. El límite es lo que obliga a terminar antes de empezar.
Medir solo una cosa. En Kanban, contar tareas terminadas sin mirar el tiempo de ciclo y la edad de cada elemento engaña: la guía pide las cuatro métricas juntas. Si quieres profundizar en cómo elegir indicadores, tienes ideas en OKR vs KPI.
Y una herramienta no arregla un método mal entendido. Si estás eligiendo software, empieza por tener claro el flujo y luego compara opciones en nuestra lista de herramientas para la gestión de proyectos.
Siguiente paso: aprender a elegir método en un máster de Project Management
Saber cuándo planificar por fases, cuándo trabajar en sprints y cuándo gestionar un flujo es una de las decisiones que más pesan en el día a día de un project manager. El Máster en Project Management de ThePower la trabaja en dos módulos consecutivos, el segundo con el enfoque ágil del PMI.
Según la ficha del programa (consultada el 11-11-2026), el módulo 3 se dedica a las «Metodologías de gestión de proyectos» y el módulo 4 a las «Metodologías Agile by Project Management Institute (PMI)». Entre lo que el programa se propone enseñar, la ficha incluye «Metodologías ágiles para aumentar la adaptabilidad, la colaboración y la velocidad de entrega». El programa reúne más de 65 horas de contenido grabado y está acreditado con «36 PDUs oficiales del PMI, obtenidos automáticamente al completar los módulos», válidos para la certificación o recertificación PMP.
Si quieres ver cómo crece una carrera en este terreno, lo tienes en del técnico al director de PMO, y el perfil completo en qué hace un project manager. Para el marco general de lo ágil, empieza por qué es la metodología Agile.
Preguntas frecuentes sobre Scrum, Kanban y cascada
¿Qué es mejor, Scrum o Kanban?
Ninguno es mejor en general: depende de cómo llega tu trabajo. Scrum encaja cuando puedes planificar en bloques y quieres entregar algo terminado cada pocas semanas. Kanban encaja cuando las peticiones llegan de forma continua y lo importante es que fluyan sin atascos. Muchos equipos empiezan con uno y acaban tomando prácticas del otro.
¿Se pueden combinar Scrum y Kanban?
Sí. The Kanban Guide de ProKanban.org admite añadir otras metodologías al sistema Kanban siempre que se mantengan sus prácticas y métricas mínimas. Lo habitual es que un equipo Scrum visualice el sprint en un tablero, limite el trabajo en curso y mida el tiempo de ciclo. A esa mezcla se la suele llamar Scrumban.
¿Quién creó el modelo en cascada?
Se atribuye a Winston W. Royce por su artículo «Managing the Development of Large Software Systems», de 1970. Pero Royce presentó ese esquema secuencial como arriesgado y propuso cinco correcciones, entre ellas diseñar antes, construir un piloto e implicar al cliente. En su artículo no aparece la palabra waterfall: el nombre llegó después.
¿Cuáles son las fases del modelo en cascada?
En el esquema de Royce de 1970, las fases son requisitos del sistema, requisitos del software, análisis, diseño del programa, codificación, pruebas y operación. Muchas explicaciones actuales agrupan esos pasos en menos fases, pero la lógica es la misma: cada fase parte del resultado de la anterior, y Royce ya pedía revisar con el cliente en varios puntos.
¿Kanban tiene sprints?
No. Kanban trabaja en flujo continuo y no fija ciclos de duración cerrada. En lugar de un objetivo por sprint, usa una expectativa de nivel de servicio: una previsión de cuánto tarda un elemento en terminarse, con su probabilidad. Puedes revisar el flujo con la frecuencia que quieras, pero la guía no obliga a ninguna reunión periódica.
