Agilidad

Scrum o Kanban: ¿qué metodología ágil elegir para su equipo?

Por Codevista InnovationsPublicado el 12 de octubre de 2026Actualizado el 15 de octubre de 20269 min de lectura

Scrum organiza el trabajo en sprints de un mes como máximo, con tres responsabilidades (Product Owner, Scrum Master y Developers) y eventos fijos; Kanban gestiona un flujo continuo sin roles obligatorios, limitando el trabajo en curso. Elija Scrum cuando un equipo construye un producto y puede proteger un objetivo durante unas semanas, y Kanban cuando las peticiones llegan sin avisar (soporte, mantenimiento, operaciones). Scrumban combina ambos.

¿Cuál es la diferencia entre Scrum y Kanban?

Ambos enfoques comparten los principios ágiles: hacer visible el trabajo, entregar en partes pequeñas y mejorar a partir de los hechos. Se diferencian en el grado de estructura. Scrum es un marco de trabajo descrito en la Guía Scrum, con responsabilidades, eventos y artefactos definidos. Kanban es un método de gestión del flujo: se visualiza el proceso actual, se limita el trabajo en curso y se mejora paso a paso.

• Cadencia: sprints de duración fija (un mes o menos) frente a un flujo continuo sin iteraciones obligatorias.
• Roles: Product Owner, Scrum Master y Developers frente a ningún rol nuevo impuesto.
• Eventos: el Sprint y, dentro de él, Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective, frente a rituales elegidos por el propio equipo.
• Limitación del trabajo: lo que entra en el sprint frente a límites de WIP por cada etapa del flujo.
• Medición: cumplimiento del objetivo del sprint (la velocidad es solo una práctica habitual) frente a lead time, rendimiento y antigüedad de las tareas.
• Cambios: objetivo del sprint protegido y alcance renegociable con el Product Owner, frente a nuevas prioridades aceptadas en cuanto queda un hueco libre.

Sprints o flujo continuo: cadencia, roles y eventos

Lo que exige la Guía Scrum

El sprint es el contenedor de todos los demás eventos. Su duración es fija y de un mes como máximo; muchos equipos de desarrollo de software optan por sprints más cortos. El Sprint Planning define el objetivo del sprint y el trabajo que contribuye a él. El Daily Scrum, limitado a 15 minutos, permite a los Developers inspeccionar su avance hacia ese objetivo y ajustar su plan. La Sprint Review es una sesión de trabajo con las partes interesadas sobre el resultado obtenido y los siguientes pasos, no una simple demostración. La Sprint Retrospective se centra en la forma de trabajar.

El Product Owner es responsable de maximizar el valor del producto y de gestionar el Product Backlog, incluido su orden de prioridad. El Scrum Master es responsable de implantar Scrum y de la eficacia del Scrum Team. Los Developers, es decir, todas las personas que producen el incremento, sea cual sea su especialidad, se comprometen a entregar en cada sprint un incremento utilizable que cumpla la Definition of Done (definición de terminado). La Guía Scrum indica que un Scrum Team suele tener diez personas o menos.

Lo que Kanban deja abierto

Kanban no reorganiza el equipo. Se cartografían las etapas reales del trabajo (por analizar, en curso, en revisión, entregado), se escriben las reglas para pasar de una columna a otra y después se eligen los rituales: una reunión diaria delante del tablero, una revisión periódica del flujo. Esta flexibilidad permite arrancar rápido, pero se convierte en un riesgo si nadie se hace cargo de la mejora.

Límites de WIP, métricas y cambios durante el sprint

El límite de WIP (work in progress, trabajo en curso) es el núcleo de Kanban. Si la columna «en revisión», limitada a tres elementos, está llena, ya no entra nada más en ella: en lugar de empezar otra cosa, el equipo ayuda a terminar lo que está esperando. Se reduce la multitarea y los cuellos de botella salen a la luz. La ley de Little formaliza esta intuición: en un flujo estable y con el mismo rendimiento, más trabajo en curso significa, de media, plazos más largos.

• Scrum: lo primero es comprobar si se ha alcanzado el objetivo del sprint y si el incremento está realmente terminado. La Guía Scrum no prescribe la velocidad; es una herramienta interna de previsión, no un indicador de rendimiento para comparar equipos.
• Kanban: el lead time (desde la petición hasta la entrega), el cycle time (desde el inicio del trabajo hasta la entrega), el rendimiento (throughput) y la antigüedad de las tareas en curso responden a la pregunta de cualquier solicitante: «¿cuándo estará listo?»

En cuanto a los cambios, la Guía Scrum es clara: ningún cambio debe poner en peligro el objetivo del sprint. El alcance puede renegociarse con el Product Owner, que es el único facultado para cancelar un sprint que ya no tenga sentido. En Kanban, la prioridad se decide cuando queda un hueco libre: una incidencia urgente puede pasar delante sin romper ningún compromiso.

Scrum o Kanban: ¿qué metodología para qué equipo?

El criterio adecuado no es el tamaño de la empresa ni el sector, sino la naturaleza de las peticiones que recibe el equipo.

• Scrum conviene a los equipos que construyen un producto con un objetivo: una plataforma SaaS, una aplicación de negocio, un nuevo servicio digital. Pueden mostrar un resultado utilizable al final de cada sprint y ajustar lo que viene después.
• Kanban conviene al trabajo continuo e imprevisible: soporte de aplicaciones, mantenimiento correctivo, operaciones, tramitación de expedientes o peticiones internas de un equipo de RRHH o de marketing.
• Scrumban conviene cuando el backlog es estable pero las urgencias son frecuentes.

Dentro de un mismo departamento de sistemas de información, en Casablanca o en cualquier otro lugar, ambos pueden convivir: el equipo que rediseña el portal de clientes trabaja con Scrum y el que mantiene la producción, con Kanban. Cuando varios equipos Scrum entregan un mismo producto, la cuestión pasa a ser la agilidad a escala con SAFe; para las funciones ajenas a TI, consulte la agilidad más allá de TI.

Scrumban: cuándo combinar Scrum y Kanban

Scrumban no tiene un documento de referencia comparable a la Guía Scrum: es una práctica que conserva parte de la estructura de Scrum y le añade la gestión del flujo. Hay dos puntos de partida habituales.

• Un equipo Scrum que incorpora Kanban mantiene sprints, roles y eventos, pero gestiona su Sprint Backlog con límites de WIP y hace seguimiento de su cycle time.
• Un equipo Kanban que incorpora cadencia mantiene el flujo continuo, pero instaura una revisión y una retrospectiva en fechas fijas.

Scrumban fracasa cuando se usa como excusa para eliminar lo que incomoda: ni objetivo, ni límites respetados, ni retrospectiva. Si el equipo ya no sabe decir qué reglas sigue, aquello ha dejado de ser Scrumban.

Los errores más frecuentes con Scrum y con Kanban

Antipatrones de Scrum

• El Product Owner de fachada, sin poder real para arbitrar las prioridades.
• El Scrum Master secretario, que organiza las reuniones pero no elimina ningún obstáculo.
• El sprint sin objetivo, una simple lista de tareas que cualquier urgencia hace descarrilar.
• La velocidad como indicador de rendimiento, que empuja a inflar las estimaciones.
• La retrospectiva sin consecuencias, en la que los mismos problemas vuelven sprint tras sprint.

Antipatrones de Kanban

• El tablero sin límites: se empieza todo lo que llega; no es más que una lista en columnas.
• Límites que se superan cada semana «de forma excepcional» y que, por tanto, no existen.
• Reglas implícitas: nadie sabe qué significa «terminado» ni quién elige la siguiente petición.
• Ninguna revisión del flujo: el equipo padece su tablero en lugar de mejorarlo.

Lista de verificación: cómo elegir entre Scrum y Kanban

1. ¿Puede agruparse el trabajo en torno a un objetivo que se mantenga durante un sprint (un mes como máximo) sin interrupciones constantes? Si es así, Scrum es un buen candidato.
2. ¿Una parte importante de las peticiones es urgente e imprevisible? Opte por Kanban, o por una capacidad reservada en Scrumban.
3. ¿Hay una persona capaz de arbitrar las prioridades con verdadera autoridad? Scrum la necesita desde el principio.
4. ¿Está la organización dispuesta a cambiar roles y reuniones? Si no, Kanban permite empezar con el proceso actual.
5. ¿Lo que más quieren saber sus solicitantes es cuándo estará listo? Las métricas de flujo responden directamente a esa pregunta.
6. ¿Trabajan varios equipos sobre un mismo producto? Necesitará además un marco de agilidad a escala.

Sea cual sea la elección, forme a la vez al equipo y a quienes fijan sus prioridades. Codevista Innovations ofrece una formación en Scrum y una formación en Kanban, en modalidad presencial en todo Marruecos, híbrida o a distancia; nuestro expediente de cualificación para la financiación CSF de la OFPPT (los Contratos Especiales de Formación del organismo público marroquí de formación profesional) está en curso. Para elegir la más adecuada, o para diseñar un programa a medida a partir de una auditoría de competencias, contáctenos.

Preguntas frecuentes

¿Se puede pasar de Scrum a Kanban en mitad de un proyecto?

Sí, es habitual cuando un producto pasa de la fase de construcción a la de mantenimiento. Conserve el tablero existente, añada límites de WIP y reglas explícitas y, después, aligere los sprints una vez que el flujo se haya estabilizado. Mantenga una retrospectiva periódica: suele ser el primer ritual que se abandona, cuando es precisamente el que permite corregir la transición.

¿Sirve Kanban para un equipo que no es de informática?

Sí. Kanban no presupone ni código ni software: basta con un trabajo que pase por etapas identificables. Un equipo de RRHH que gestiona procesos de selección, un departamento de compras o un equipo de marketing pueden visualizar su flujo, limitar el trabajo en curso y hacer seguimiento de sus plazos. Suele ser la puerta de entrada más sencilla a la agilidad para las funciones ajenas a TI.

¿Hace falta un Scrum Master en un equipo Kanban o Scrumban?

Kanban no impone ningún rol, así que tampoco un Scrum Master. En la práctica, alguien debe velar por que se respeten los límites de WIP, dinamizar la revisión del flujo e impulsar las acciones de mejora. En Scrumban, si el equipo mantiene los eventos de Scrum, sigue siendo útil confiar a una persona la responsabilidad de que sean eficaces.

¿Qué formación elegir: Scrum o Kanban?

La que corresponda al trabajo real del equipo. Una formación en Scrum es útil para un Product Owner, un Scrum Master o los Developers de un equipo de producto. Una formación en Kanban sirve más a los responsables de soporte, de operaciones o de servicios internos. En una organización mixta, formar a los mandos en ambos métodos evita que la elección de metodología se convierta en una guerra de bandos.