¿Qué es Scrumban y cómo funciona?

Scrumban es un framework de gestión de trabajo ágil que combina la estructura y cadencia de Scrum con el sistema de flujo continuo y visualización de Kanban. Fue conceptualizado por Corey Ladas en su libro "Scrumban: Essays on Kanban Systems for Lean Software Development" (2009) originalmente como un método de transición para equipos que querían evolucionar de Scrum hacia Lean/Kanban.

Sin embargo, con el tiempo, Scrumban se ha consolidado como un enfoque válido por derecho propio, adoptado por equipos que encuentran que ni Scrum puro ni Kanban puro se ajustan completamente a su contexto de trabajo. Scrumban toma lo mejor de ambos mundos: de Scrum, los roles, las ceremonias y los sprints; de Kanban, los límites de WIP, la visualización del flujo y el enfoque en la mejora continua del proceso.

Scrumban es especialmente popular en equipos que manejan una combinación de trabajo planificado (features, proyectos) y trabajo no planificado (incidencias, soporte, bugs urgentes), como equipos de operaciones, soporte técnico, DevOps o equipos de producto maduros que necesitan más flexibilidad que la que ofrece Scrum estricto.

Scrumban combina elementos selectivos de ambos frameworks:

Elementos heredados de Scrum

• Roles: mantiene los roles de Product Owner (priorización) y Scrum Master/facilitador (mejora del proceso), aunque con menos rigidez que en Scrum puro.
• Sprint Planning: se mantiene la planificación periódica, aunque puede ser más flexible en frecuencia (on-demand planning).
• Retrospectivas: se mantienen para la mejora continua del proceso.
• Sprint Review/Demo: se conserva para mostrar trabajo completado a stakeholders.
• Backlog: el Product Backlog se mantiene como fuente de trabajo priorizado.

Elementos heredados de Kanban

• Tablero visual: visualización del flujo de trabajo con columnas que representan cada fase del proceso.
• Límites de WIP (Work In Progress): restricciones explícitas sobre cuántos elementos pueden estar en cada fase simultáneamente.
• Pull system: el trabajo se "tira" (pull) cuando hay capacidad, en lugar de "empujarse" (push) al equipo.
• Flujo continuo: el trabajo fluye a través del sistema sin esperar al final de un sprint para entregar.
• Métricas de flujo: Cycle Time, Lead Time, Throughput y CFD (Cumulative Flow Diagram) como indicadores principales.
• Políticas explícitas: reglas claras sobre cuándo un item puede moverse de una columna a otra.

Elementos únicos de Scrumban

• Planning on demand: en lugar de planificar al inicio de cada sprint fijo, la planificación se dispara cuando el trabajo en el backlog listo cae por debajo de un umbral definido.
• Triage: proceso de clasificación y priorización de trabajo entrante, especialmente útil para trabajo no planificado.
• Buckets de capacidad: asignación deliberada del porcentaje de capacidad del equipo a diferentes tipos de trabajo (ej: 60% features, 20% bugs, 20% deuda técnica).
• Feature freeze: punto en el que se deja de añadir trabajo nuevo para completar el trabajo en progreso antes de una release.

Tablero Scrumban típico

┌──────────┬────────────┬──────────────┬──────────┬──────────┬────────┐ │ Backlog │ Ready │ In Progress │ Review │ Testing │ Done │ │ │ (WIP: 5) │ (WIP: 3) │ (WIP: 2) │ (WIP: 2) │ │ ├──────────┼────────────┼──────────────┼──────────┼──────────┼────────┤ │ Feature E│ Feature D │ Feature B │Feature A │ Bug #45 │Story X │ │ Feature F│ Bug #47 │ Feature C │ │ │Bug #44 │ │ Bug #48 │ Tech Debt 3│ Bug #46 │ │ │Story Y │ │ Tech D 4 │ │ │ │ │ │ │ Feature G│ │ │ │ │ │ └──────────┴────────────┴──────────────┴──────────┴──────────┴────────┘

Veamos cómo un equipo de desarrollo de producto adopta Scrumban para gestionar su flujo de trabajo mixto:

Contexto del equipo:

El equipo "Plataforma" de una empresa SaaS gestiona:

• Features nuevas planificadas en el roadmap (60% del tiempo).
• Bugs reportados por usuarios y soporte (20% del tiempo).
• Deuda técnica y mejoras de infraestructura (20% del tiempo).

Con Scrum puro, el equipo sufría porque los bugs urgentes interrumpían constantemente los sprints, y con Kanban puro echaban de menos la estructura de la planificación periódica.

Implementación de Scrumban:

Paso 1 - Tablero con límites de WIP:

El equipo configura su tablero con columnas y límites:

Reglas del tablero: - Ready: máximo 6 items (disparar planning cuando baje de 3) - In Progress: máximo 4 items (2 features + 1 bug + 1 tech debt) - Code Review: máximo 3 items - Testing: máximo 2 items - Si una columna alcanza su límite, nadie puede mover trabajo a esa columna hasta que se libere capacidad

Paso 2 - Buckets de capacidad:

Distribución semanal del equipo (6 developers): ├── Features planificadas: 3.5 developers (58%) ├── Bugs y soporte: 1.5 developers (25%) └── Deuda técnica: 1 developer (17%) Rotación: cada semana un developer diferente cubre bugs/soporte

Paso 3 - Planning on demand:

En lugar de Sprint Planning fijo cada 2 semanas, el equipo planifica cuando la columna "Ready" baja de 3 items:

Semana 1: Ready tiene 6 items → No hay planning Semana 2: Ready baja a 4 items → No hay planning todavía Semana 3: Ready baja a 2 items → Trigger! Planning session El PO trae 8 items priorizados del Backlog El equipo refina y selecciona 5 para Ready Ready vuelve a 7 items

Paso 4 - Gestión del trabajo urgente:

Cuando llega un bug crítico de producción:

1. El item entra directamente en una fila de "Expedite" (carril rápido) que no tiene límite de WIP.
2. El developer en rotación de soporte lo toma inmediatamente.
3. Se salta las fases normales si es necesario.
4. Se registra para analizar en la retrospectiva la causa raíz.

Paso 5 - Retrospectiva quincenal:

El equipo se reúne cada 2 semanas para analizar métricas:

Métricas del período: ├── Throughput: 12 items completados (8 features, 3 bugs, 1 tech debt) ├── Cycle Time mediano: 3.5 días ├── Cycle Time p85: 6 días ├── Items bloqueados: 2 (ambos por dependencias externas) └── Bugs expedite: 1 (caída del servicio de pagos) Decisiones: → Reducir WIP de "In Progress" de 4 a 3 (mejorar flow) → Crear checklist de dependencias para detectar bloqueos temprano → Mantener distribución actual de buckets (funciona bien)

Scrumban ofrece ventajas significativas para equipos que necesitan flexibilidad:

Flexibilidad sin perder estructura: muchos equipos encuentran que Scrum es demasiado prescriptivo (especialmente con trabajo no planificado) y Kanban demasiado abierto (sin la disciplina de planificación y retrospectivas). Scrumban ofrece el punto medio: suficiente estructura para mantener la disciplina, suficiente flexibilidad para adaptarse a la realidad.

Manejo eficiente del trabajo no planificado: en equipos de soporte, operaciones o DevOps, una parte significativa del trabajo es reactivo. Scrumban, con sus carriles de expedite, buckets de capacidad y sistema pull, maneja esta mezcla de trabajo planificado y no planificado de forma natural, sin la fricción que genera en Scrum puro.

Mejora continua basada en datos: las métricas de flujo heredadas de Kanban (Cycle Time, Throughput, CFD) proporcionan datos objetivos para la mejora del proceso. Los equipos no dependen de sensaciones subjetivas sino de métricas concretas para tomar decisiones sobre su forma de trabajar.

Transición suave: para equipos que practican Scrum y quieren evolucionar, Scrumban ofrece una transición gradual. No es necesario abandonar Scrum de golpe; se pueden introducir elementos de Kanban progresivamente (primero WIP limits, luego métricas de flujo, luego planning on demand) hasta encontrar el equilibrio adecuado.

Escalabilidad: Scrumban se adapta bien a diferentes tamaños de equipo y complejidades. Desde equipos pequeños de 3-4 personas hasta equipos más grandes, las reglas se pueden ajustar sin cambiar la esencia del enfoque.

Reducción de desperdicios: el sistema pull y los límites de WIP eliminan la sobreproducción (construir más de lo que se puede revisar/testear) y reducen la multitarea, que es una de las principales fuentes de ineficiencia en los equipos de desarrollo.

Scrumban vs. Scrum vs. Kanban

Aspecto	Scrum	Kanban	Scrumban
Cadencia	Sprints fijos	Flujo continuo	Sprints flexibles o flujo
Roles	PO, SM, Devs (obligatorios)	No prescribe roles	PO, facilitador (flexibles)
Planificación	Sprint Planning fijo	On demand	On demand con trigger
WIP limits	No explícitos	Obligatorios	Obligatorios
Métricas	Velocidad	Flow metrics	Ambas
Cambios mid-sprint	No recomendados	Siempre permitidos	Permitidos con criterio
Ideal para	Equipos de producto	Soporte, operaciones	Trabajo mixto

¿Scrumban es reconocido como framework oficial?

Scrumban no tiene una guía oficial como la Guía de Scrum ni una certificación estandarizada como SAFe. Es un enfoque pragmático que ha sido documentado por Corey Ladas y adoptado por la comunidad ágil. Su falta de certificación formal es, para muchos, una ventaja: no hay dogmas ni rigidez prescriptiva.

¿Necesito límites de WIP si ya hago Scrum?

Si notas que tu equipo trabaja en demasiadas cosas simultáneamente, que items permanecen "en progreso" durante todo el sprint sin completarse, o que el código review se acumula, entonces sí. Los límites de WIP son una de las contribuciones más valiosas de Kanban a cualquier equipo, incluso los que no adoptan Scrumban formalmente.

¿Puedo hacer Scrumban sin sprints?

Sí. En su forma más evolucionada, Scrumban puede prescindir completamente de sprints y operar en flujo continuo con planning on demand. Sin embargo, mantener alguna forma de cadencia regular (aunque sea solo para retrospectivas y demos) es recomendable para no perder las oportunidades de inspección y adaptación.

¿Cómo establezco los límites de WIP iniciales?

Una regla general es empezar con un WIP limit igual al número de personas del equipo o ligeramente inferior. Por ejemplo, para un equipo de 6, empezar con WIP limit de 5-6 para "In Progress". Si el flujo es demasiado restrictivo, aumentar gradualmente. Si hay demasiada multitarea, reducir. La clave es experimentar y ajustar.

¿Scrumban funciona para equipos distribuidos o remotos?

Sí. Las herramientas de gestión de trabajo como Jira, Trello, Linear o Azure DevOps permiten implementar tableros Scrumban visuales con límites de WIP y métricas de flujo de forma remota. La retrospectiva y la planificación se pueden hacer por videoconferencia, al igual que en Scrum remoto.

¿Cuándo debería un equipo considerar Scrumban?

Scrumban es especialmente adecuado cuando: el equipo tiene una mezcla significativa de trabajo planificado y no planificado, los sprints se interrumpen frecuentemente con urgencias, el equipo encuentra Scrum demasiado prescriptivo pero necesita más estructura que Kanban puro, o el equipo quiere evolucionar gradualmente desde Scrum hacia un enfoque más Lean.