¿Qué es Scrumban?

Qué es Scrumban en realidad

Scrumban se queda con las partes de Kanban y de Scrum que se ganan el sitio, y descarta el resto. De Kanban toma el tablero visual, el flujo de trabajo por columnas y un límite explícito a cuánto trabajo hay en curso: lo que hace legible el flujo. De Scrum toma el sprint de tiempo acotado: lo que convierte un backlog en un plan.

Lo que se salta: las dailies, las reuniones de refinamiento del sprint, las ceremonias de puntos de historia, las retrospectivas como ritual. Eso funciona para diez ingenieros en una organización engrasada; no funciona para un fundador que intenta entregar un sábado.

El nombre viene de Corey Ladas, cuyo ensayo y posterior libro Scrumban describía cómo los equipos Scrum podían pasar de iteraciones fijas a un flujo basado en tirar del trabajo (pull).

Scrumban vs Kanban vs Scrum: diferencias

Los tres se diferencian sobre todo en dos cosas: si el trabajo se planifica en bloques de tiempo acotado y cuánto proceso rodea al tablero.

Fuentes: la Guía de Scrum para sprints, roles y eventos; la Guía de Kanban para el flujo y los límites al trabajo en curso.

¿Cómo es un tablero Scrumban?

Un tablero Scrumban es un tablero Kanban con un sprint superpuesto. Las columnas muestran dónde está el trabajo; el sprint dice de qué parte del backlog va esta semana. Un tablero mínimo tiene cuatro columnas:

• Backlog: todo lo que podrías hacer. Sin ordenar en la parte de abajo, ordenado en la de arriba.
• Todo: lo que has decidido hacer a continuación. Pequeño a propósito: cuando se vacía, es la señal para planificar.
• Doing: aquello en lo que alguien (una persona o un agente de IA) está trabajando ahora mismo.
• Done: el trabajo terminado. Se limpia o se archiva al final de un sprint.

¿Cómo se monta un tablero Scrumban?

1. Crea las cuatro columnas: Backlog, Todo, Doing, Done.
2. Mete en Backlog todo lo que tengas en mente. No lo ordenes todo: ordena la parte de arriba.
3. Decide cuánto puede haber en Doing a la vez. Para una persona, una o dos cosas; para un equipo pequeño, más o menos una por persona.
4. Elige la duración del sprint (una o dos semanas) y escribe un objetivo de una frase. Pasa a Todo solo lo que sirva a ese objetivo.
5. Trabaja tirando del trabajo: cuando algo de Doing esté terminado, coge la siguiente tarjeta de lo alto de Todo. Nadie le empuja trabajo a nadie.
6. Planifica cuando Todo se esté vaciando, no según el calendario. Al final del sprint, mira qué se hizo y qué no, y empieza el siguiente.

Por qué Weft elige Scrumban

Weft existe porque la mayoría de los gestores de tareas están hechos para uno de dos extremos: o una app de lista de tareas en solitario (lista infinita, sin cadencia) o una suite Agile para cincuenta personas (sobrecarga de proceso para un fundador de uno). Scrumban está justo en el medio: estructura suficiente para forzar una entrega semanal o quincenal, no tanta que te pases el día de entrega administrándola.

Cómo lo implementa Weft

• Cuatro columnas por defecto: Backlog, Todo, Doing, Done. El trabajo en curso se limita por lo que espera por ti, no por un número en cada columna. La Guía de Kanban considera una política explícita para limitar el trabajo en curso como parte de la definición del flujo de trabajo, de modo que solo se incorporan elementos nuevos a medida que se libera capacidad.
• Un sprint activo a la vez, con un objetivo opcional. Los sprints son opcionales: sáltatelos si Kanban puro te encaja. La Guía de Scrum define los Sprints como eventos de duración fija de un mes o menos, y un nuevo Sprint empieza inmediatamente después de que concluya el anterior.
• Las tareas tienen prioridad, estimación, fecha límite y un vínculo opcional a un sprint. Sin épicas, sin flujos de trabajo, sin campos personalizados.
• El tiempo de ciclo empieza cuando una tarea pasa a una columna con semantic="doing" y termina en "done". Las cifras salen del uso honesto, no de la aritmética de puntos de historia.

Scrumban con agentes de IA

Tirar del trabajo es también lo que hace que Scrumban funcione con agentes de IA. Un agente conectado a Weft por MCP coge él mismo la siguiente tarjeta: start_task la reclama, para que un segundo agente no pueda coger la misma, y complete_task la cierra con lo que se hizo y las pruebas. Cuando un agente necesita una decisión, te pregunta en lugar de adivinar, y mientras haya demasiado trabajo terminado esperándote, los agentes dejan de empezar tareas nuevas. Es el límite de Kanban al trabajo en curso, aplicado al único recurso que no escala: tu atención.

Cuándo Scrumban no es el método adecuado

• Llevas varios equipos Scrum a la vez. La Guía de Scrum sitúa un Scrum Team en normalmente 10 personas o menos, y dice que los productos más grandes deben organizarse en varios Scrum Teams que comparten un mismo Product Goal y un mismo Product Backlog. Informes a nivel de programa, velocidad compartida, dependencias entre equipos: el Scrum completo en Jira se gana el sueldo. La Guía de Nexus está escrita para esa situación: varios Scrum Teams que trabajan desde un único Product Backlog, con prácticas adicionales para detectar y resolver las dependencias entre equipos.
• Haces soporte puro u operaciones continuas. No hace falta cadencia de sprints: Kanban puro o un sistema de tickets encajan mejor.
• Necesitas diagramas de Gantt y cronogramas. Scrumban se centra en el sprint, no en el grafo de dependencias.

Preguntas sobre Scrumban