Scrumban: mezclar Scrum y Kanban sin crear un Frankenstein

Scrumban nació de una frustración muy concreta: equipos que intentaban trabajar con Scrum y descubrían que media semana se les iba en interrupciones. Soporte, incidencias, mantenimiento, urgencias de clientes: trabajo legítimo que no cabe en la caja del sprint. El término lo popularizó Corey Ladas a finales de los 2000 con una idea sencilla: aplicar el pensamiento lean de Kanban sobre la estructura que Scrum ya había instalado.

La tensión que resuelve es fácil de enunciar. Scrum te da cadencia: un ritmo compartido, un objetivo cada pocas semanas, un momento fijo para revisar el proceso. Kanban te da flujo: el trabajo entra cuando hay capacidad, no cuando arranca una iteración, y lo que importa no es cuánto prometiste sino cuánto termina. La mayoría de los equipos de 2 a 15 personas no vive en un mundo puro: maneja proyectos con fechas y, al mismo tiempo, una cola de soporte que no negocia. Para ese mundo existe scrumban.

Si tu duda previa es elegir entre los dos métodos puros, la comparación directa está en Scrum vs Kanban: cuál usar y cuándo. Aquí asumimos que ya sabes que necesitas un poco de ambos, y vamos a la receta.

Scrumban no es un promedio difuso: es una combinación concreta de piezas que ya funcionan por separado. De Scrum conserva la estructura social —el ritmo y los momentos de ajuste—; de Kanban importa las reglas de flujo. Así queda la receta:

El corazón del sistema es el tablero: columnas visibles, dueño por tarjeta y límites a la vista. Si el tuyo aún no existe, ármalo primero con la guía de cómo hacer un tablero kanban y después suma el resto.

Para ver qué aporta el híbrido conviene poner los tres métodos lado a lado. Ninguno es «mejor»: cada uno optimiza algo distinto.

Fíjate en el patrón: scrumban no inventa nada nuevo, combina. Su propuesta es que puedes conservar el ritmo y el aprendizaje de Scrum sin renunciar a la honestidad de flujo de Kanban.

Antes de los pasos, la duda literal que trae a mucha gente hasta aquí: sí, es compatible mezclar kanban y scrum; la prueba es que la mezcla tiene nombre propio. La migración desde Scrum puro cabe en uno o dos sprints y no necesita permiso de nadie externo al equipo:

1. Mantén el objetivo de sprint y la retrospectiva. La cadencia es lo mejor que Scrum le da a tu equipo: no la sueltes. Lo que cambia es el compromiso de alcance: el sprint tiene un objetivo que ordena prioridades, no una lista congelada de tarjetas.
2. Suelta la estimación rígida. Deja de negociar puntos y usa el lead time histórico por tipo de trabajo. Es un número que se corrige solo y evita el teatro de la planificación.
3. Impón límites WIP por columna. Empieza con «En curso» igual a la mitad de las personas del equipo y ajústalo con datos. Sin WIP no hay scrumban: hay Scrum con columnas decorativas.
4. Explicita las políticas de cada columna. Qué debe tener una tarjeta para entrar, quién puede tomarla y qué la saca. Las políticas escritas son las que permiten meter una urgencia sin discutir cada vez de nuevo.
5. Mide lead time y cumplimiento. Cuánto tarda cada tipo de trabajo y qué porcentaje del objetivo se cumplió. Con esas dos series, la retrospectiva deja de ser impresiones y pasa a ser ingeniería de proceso.

El paso 3 es el que más cuesta y el que más rendimiento da: cómo poner el límite, qué hacer cuando «no cabe» y cómo negociarlo con el cliente están desarrollados en límites WIP en kanban.

Un híbrido mal ejecutado es peor que cualquiera de los dos métodos puros: hereda los costos de ambos y los beneficios de ninguno. Estos son los dos Frankenstein más comunes:

• Ceremonias sin WIP. El equipo conserva sprints, dailies y retrospectivas, pero «En curso» crece sin techo. Resultado: sprint infinito, diez tareas al 60 % y ceremonias convertidas en teatro de reporte. Si te suena, aclara primero qué te conviene de cada método en Scrum vs Kanban.
• WIP sin retrospectiva. El caso espejo: límites bien puestos que se pudren porque nadie los revisa. El WIP se sube «temporalmente» un martes y sigue ahí tres meses; las políticas se vuelven folclore. El límite es una hipótesis que la retrospectiva valida o corrige: uno sin la otra no funciona.

Hay un tercer error más silencioso: mezclar vocabularios sin decidir quién manda. Si el orden de la cola se negocia cada mañana, no hay método: hay humor. La prioridad la pone el objetivo del sprint y el orden del backlog; las urgencias se cuelan solo por la puerta del WIP, nunca por la del favor.

Scrumban brilla en equipos de 2 a 15 personas que viven con un pie en cada mundo: agencias con varios clientes, áreas internas que mantienen sistemas mientras construyen los nuevos, equipos de producto con SLA de soporte. También es la puerta de entrada más honesta para equipos que probaron Scrum y no les funcionó: no tienen que tirar lo aprendido, solo soltar la parte que no encajaba.

No lo necesitas si tu contexto es puro: un equipo de producto dedicado, con alcance estable y stakeholders alineados, sigue mejor con Scrum completo; un flujo de tickets puro opera mejor con Kanban sin cadencia. El híbrido es para la mezcla, no para evitar decidir.

Y si quieres un tablero con límites WIP de fábrica —columnas con máximo, dueño por tarjeta, checklists y procesos, sin cuenta ni asientos, con todo en un JSON local de tu carpeta— Hito está pensado justamente para equipos de 1 a 15 personas.

👉 Prueba Hito gratis — sprints con objetivo y WIP visible, local-first, sin nube.