Scrumban: combinando Scrum y Kanban

Scrumban es lo que obtiene cuando deja de forzar una elección entre Scrum y Kanban. Los equipos que necesitan planificación estructurada pero no pueden permitirse sprints rígidos recurren primero a scrumban.

¿Qué es Scrumban?

Scrumban es un marco ágil híbrido que superpone la mecánica de flujo continuo de Kanban sobre la disciplina de planificación de Scrum. El trabajo se mueve a través de un tablero basado en pull con límites de Trabajo en Curso (WIP), pero los eventos de planificación se activan bajo demanda en lugar de seguir un reloj de sprint fijo.

Corey Ladas acuñó el término en un ensayo de 2008 y luego lo desarrolló en su libro Scrumban: Essays on Kanban Systems for Lean Software Development. Su argumento central: Scrum es un buen andamiaje para equipos nuevos en agile, pero a medida que los equipos maduran deberían eliminar las ceremonias que no aportan valor y conservar las que sí. El modelo de flujo de Kanban llena los vacíos. El resultado es un marco lo suficientemente flexible para trabajo de mantenimiento, colas de soporte y operaciones de marketing, ninguno de los cuales encaja limpiamente en sprints de dos semanas.

Datos clave

• El 17.º State of Agile Report (2023) encontró que el 9% de los encuestados usaba un híbrido Scrum/Kanban como su enfoque principal de entrega, frente al 6% dos años antes.
• Los equipos que implementan límites de WIP junto con un sistema pull suelen ver reducciones del 20% al 40% en el tiempo de ciclo, según datos de mejora de flujo citados en Principles of Product Development Flow de Donald Reinertsen (2009).
• Scrumban conserva los eventos de planificación, pero los activa según el tamaño de la cola, no según el calendario, de modo que el esfuerzo de planificación se mantiene proporcional al volumen real de trabajo.

Scrum vs Kanban vs Scrumban

Los tres marcos comparten un tablero y un backlog, pero divergen rápidamente en cadencia, roles y cómo entra el trabajo al sistema.

Si su equipo ya usa Scrum pero sigue forzando las reglas del sprint para atender solicitudes urgentes, ya está a mitad de camino hacia scrumban. Y si usa Kanban pero nota que nunca se detiene a reflexionar o planificar, el modelo de scrumban de "estructura solo cuando se necesita" le da un motivo para hacer una pausa.

Cómo funciona Scrumban

La mecánica de scrumban se apoya en cuatro ideas interconectadas.

Sistema pull. El trabajo no se empuja hacia los ingenieros. Se extrae. Cuando alguien termina una tarea, extrae el siguiente elemento de una cola lista hacia su columna. Esto evita que el trabajo se acumule en el carril de una sola persona y hace visibles los cuellos de botella de inmediato.

Límites de WIP. Cada columna del tablero tiene un conteo máximo. La columna "En curso" podría contener no más de tres tarjetas a la vez. Cuando la columna está llena, el equipo se enfoca en terminar antes de comenzar algo nuevo. Los límites de WIP son la palanca más poderosa para reducir el tiempo de ciclo en cualquier sistema derivado de kanban.

Cola lista. Entre el backlog y las columnas de trabajo activo se ubica una cola lista, un pequeño búfer de elementos depurados y priorizados que están genuinamente listos para extraer. La cola lista desacopla la planificación de la ejecución. La planificación puede ocurrir en una ráfaga enfocada, y luego el equipo extrae de la cola a voluntad sin necesitar que un planificador esté presente.

Activador de planificación bajo demanda. En lugar de planificar cada dos semanas sin importar qué, scrumban dispara un evento de planificación cuando la cola lista cae por debajo de un umbral establecido, digamos dos elementos por desarrollador. Esto significa que el esfuerzo de planificación se escala según la necesidad real. Las semanas tranquilas reciben un pequeño refuerzo; las semanas ocupadas podrían no necesitar planificación en absoluto.

Un diagrama de flujo acumulado es la herramienta de seguimiento natural para scrumban porque visualiza el tamaño de las colas, el WIP y el rendimiento en una sola vista. Si una banda empieza a ensancharse, el trabajo se está acumulando más rápido de lo que se está terminando.

Beneficios de Scrumban

Flujo sin caos. El modelo de flujo continuo de Kanban mantiene el trabajo en movimiento. Scrumban agrega justo la estructura suficiente para evitar que el backlog se convierta en un cementerio de tickets sin tocar.

Planificación a su propio ritmo. Los equipos que batallan con ceremonias de planificación de sprint que ocupan todo el día para dos horas de decisiones reales notarán la diferencia de inmediato. La planificación ocurre cuando la cola necesita reabastecerse, no porque el calendario lo diga.

Menor sobrecarga para equipos estables. Una vez que un equipo sabe lo que está haciendo, las ceremonias de Scrum que tenían sentido durante el arranque empiezan a sentirse redundantes. Scrumban permite a los equipos abandonar lo que no les sirve y conservar lo que sí.

Maneja tipos de trabajo mixtos. La mayoría de los equipos reales lidian tanto con trabajo planificado (nuevas funciones, proyectos) como con trabajo no planificado (errores, solicitudes, incidentes). Scrum tiene dificultades con el trabajo no planificado porque interrumpe el sprint. Scrumban lo absorbe porque el tablero siempre tiene espacio para extraer nuevos elementos hacia la cola lista fuera del ciclo normal de depuración.

Visibilidad. El tablero permanece activo en todo momento. Cualquiera puede ver qué está en curso, qué está bloqueado y qué tan cerca está la cola lista de activar la planificación. No hay que esperar a una revisión de sprint para conocer el estado del sistema.

Dónde Scrumban se queda corto

Scrumban no es una solución universal. Introduce sus propios modos de fallo.

Sin roles significa sin responsabilidad. Los roles definidos de Scrum existen porque alguien necesita ser dueño del backlog, alguien necesita facilitar y alguien necesita proteger al equipo de la expansión del alcance. Scrumban elimina estos roles por defecto. Los equipos que se saltan esa estructura a menudo terminan con un backlog sin depurar, reuniones de planificación para las que nadie se prepara y un tablero que nadie actualiza.

Los límites de WIP requieren disciplina. La primera vez que un gerente pide al equipo "solo agregar una cosa más", el límite de WIP se ajusta silenciosamente. Una vez que los límites se convierten en sugerencias, la mecánica de flujo se descompone. Scrumban solo funciona si el equipo trata los límites de WIP como restricciones estrictas.

No es ideal para trabajo de descubrimiento grande y complejo. Si está construyendo algo genuinamente desconocido, el ritmo de sprint de Scrum obliga a la reflexión y planificación que el trabajo exploratorio necesita. La planificación bajo demanda de scrumban puede permitir que los equipos pasen demasiado tiempo sin detenerse a preguntar si están construyendo lo correcto.

Difícil de medir la velocidad. Debido a que no hay sprints fijos, las métricas tradicionales de velocidad en agile no aplican directamente. Los equipos cambian al rendimiento (elementos completados por semana) y al tiempo de ciclo en su lugar. Esa es una mejor medida en la mayoría de los casos, pero requiere un cambio de mentalidad.

Cómo implementar Scrumban

Paso 1: Empiece desde su tablero actual

No rediseñe todo de una vez. Ya sea que venga de Scrum o de Kanban, conserve sus columnas y formato de tarjeta existentes. El primer cambio es invisible: está pasando de una mentalidad de empuje (asignar trabajo a las personas) a una mentalidad de extracción (dejar que las personas extraigan de la cola cuando estén listas).

Paso 2: Agregue límites de WIP a las columnas activas

Elija un número conservador para cada columna en curso, típicamente de uno a dos por miembro del equipo. Lo ajustará después de una o dos semanas. El objetivo no es elegir el número perfecto, sino hacer visibles los problemas de flujo.

Paso 3: Cree una cola lista

Agregue una columna "Lista" entre su backlog y su primera columna activa. Los elementos pasan a Lista solo cuando están depurados: definidos, estimados y genuinamente accionables. Este es su producto de planificación. El equipo extrae de Lista libremente sin necesitar un planificador presente.

Paso 4: Establezca un umbral de activación de planificación

Decida qué tan bajo puede caer la cola lista antes de ejecutar una sesión de planificación. Un punto de partida común: planificar cuando Lista caiga por debajo de un suministro de dos días. Escríbalo. El activador debe ser un número real, no "cuando se sienta bajo".

Paso 5: Realice retrospectivas ligeras

Incluso sin sprints fijos, los equipos necesitan detenerse a preguntar qué está funcionando. Programe una retrospectiva corta cada dos a cuatro semanas, o después de un número definido de elementos entregados. Manténgala corta, de 30 a 45 minutos, y enfocada en el flujo: qué nos frenó, qué ayudó y qué cosa cambiaríamos la próxima vez.

Después de algunos ciclos tendrá datos reales de rendimiento. Úselos para refinar los límites de WIP, ajustar el activador de planificación e identificar qué tipos de trabajo se mueven más rápido por el tablero. Ese es el ciclo de mejora continua en el núcleo de la metodología ágil.

Ejemplos de Scrumban por tipo de equipo

Buenas prácticas

Mantenga el tablero honesto. Actualice el estado de la tarjeta en el momento en que cambia, no en el standup, no al final del día. Un tablero desactualizado es peor que ningún tablero porque crea una falsa confianza.

Trate los límites de WIP como un contrato de equipo. Acuérdenlos juntos, escríbanlos en el tablero y exíjanse mutuamente su cumplimiento. Cuando alguien quiera exceder el límite, eso es una conversación, no una decisión unilateral.

Separe el trabajo urgente del planificado. Agregue una pequeña fila de "vía rápida" en el tablero para emergencias genuinas. Límítela a un elemento a la vez. Esto le da a los incidentes un camino sin hacer estallar el flujo principal.

Visualice el trabajo bloqueado. Use una bandera o etiqueta de color para las tarjetas bloqueadas en lugar de simplemente dejarlas en curso. El trabajo bloqueado que permanece silenciosamente dentro de un límite de WIP es desperdicio invisible.

Mida el tiempo de ciclo, no la velocidad. Rastree cuánto tiempo pasan los elementos desde Lista hasta Terminado. El tiempo de ciclo le indica qué tan predecible es su entrega. Mejorarlo es el objetivo principal del sistema pull.

Vuelva periódicamente a qué es Scrum y qué es Kanban. Scrumban toma prestado de ambos, y cuando algo no funciona ayuda volver a los principios de origen. A menudo la respuesta ya está ahí.

Si su equipo está explorando marcos más amplios para escalar, Scaled Agile Framework (SAFe) aborda tensiones similares a nivel de portafolio. Y para equipos que quieren aún menos ceremonia que scrumban, Extreme Programming (XP) va en una dirección distinta: más práctica de ingeniería, menos andamiaje de proceso.

Preguntas frecuentes

¿Scrumban tiene sprints?

No por defecto. Scrumban reemplaza los sprints fijos con planificación bajo demanda activada por el tamaño de la cola. Dicho esto, algunos equipos mantienen una cadencia de planificación quincenal flexible como función forzadora mientras usan la mecánica de flujo para el trabajo del día a día. El marco es lo suficientemente flexible para incluir sprints si le sirven al equipo.

¿Hay roles definidos en Scrumban?

No. Scrumban elimina los roles de Product Owner, Scrum Master y equipo de desarrollo que requiere Scrum. Los equipos deciden por sí mismos quién es dueño del backlog, quién facilita la planificación y quién mantiene el tablero. Muchos conservan un rol ligero de product owner porque alguien todavía necesita priorizar. Pero el marco no lo exige.

¿Es Scrumban bueno para equipos de mantenimiento?

Es uno de los mejores ajustes. El trabajo de mantenimiento es impredecible, llega en tamaños variables y no encaja bien en ciclos de planificación de sprint. El sistema pull y la planificación bajo demanda permiten a los equipos de mantenimiento manejar lo que sea que aparezca sin negociar constantemente el alcance contra un límite de sprint.

¿En qué se diferencia Scrumban de simplemente "hacer Kanban"?

La principal diferencia es la estructura. El Kanban puro no tiene ceremonias obligatorias, ni activadores de planificación, ni un ciclo de reflexión incorporado. Scrumban agrega una cola lista, un umbral de activación de planificación y retrospectivas opcionales. Es Kanban con barandillas para equipos que descubrieron que el flujo puro dejaba demasiado al azar.

¿Qué métricas deberían rastrear los equipos de Scrumban?

El tiempo de ciclo (tiempo desde Lista hasta Terminado), el rendimiento (elementos completados por semana) y el tamaño de la cola son las tres métricas centrales. Un diagrama de flujo acumulado traza las tres en una sola vista y hace evidentes los cuellos de botella. Evite rastrear la velocidad a menos que haya introducido sprints, porque la velocidad es una medida basada en sprints.

Scrumban sigue evolucionando a medida que los equipos encuentran nuevas combinaciones de las ceremonias de Scrum y las herramientas de flujo de Kanban. La permanencia del marco viene de una idea simple: optimizar el proceso para el trabajo real, no al revés. Empiece con su tablero actual, agregue límites de WIP y observe lo que revelan las restricciones.

Lecturas relacionadas

• Qué es Scrum
• Qué es Kanban
• Scrum vs Kanban
• Límites de WIP
• Diagrama de flujo acumulado
• Planificación de sprint
• Velocidad en Agile
• Qué es la metodología ágil
• Extreme Programming
• Scaled Agile Framework (SAFe)