O que é Scrumban?

O que o Scrumban é, de fato

O Scrumban mantém as partes do Kanban e do Scrum que se pagam e descarta o resto. Do Kanban, pega o quadro visual, o fluxo de trabalho por colunas e um limite explícito de quanto pode estar em andamento — o que torna o fluxo legível. Do Scrum, pega a sprint de duração fixa — o que transforma um backlog em um plano.

O que ele pula: dailies, reuniões de grooming da sprint, cerimônias de story points, retrospectivas como ritual. Isso funciona para dez engenheiros em uma organização bem afinada; não funciona para um fundador tentando entregar num sábado.

O nome vem de Corey Ladas, cujo ensaio e, depois, o livro Scrumban descreveram como times Scrum podiam sair das iterações fixas rumo a um fluxo puxado.

Scrumban vs Kanban vs Scrum

Os três diferem principalmente em duas coisas: se o trabalho é planejado em blocos de tempo fixos e quanto processo existe em volta do quadro.

Fontes: o Guia do Scrum para sprints, papéis e eventos; o Guia do Kanban para fluxo e limites de trabalho em andamento.

Como é um quadro Scrumban?

Um quadro Scrumban é um quadro Kanban com uma sprint por cima. As colunas mostram onde o trabalho está; a sprint diz de qual parte do backlog esta semana trata. Um quadro mínimo tem quatro colunas:

• Backlog — tudo o que você talvez faça. Desordenado embaixo, ordenado em cima.
• Todo — o que você decidiu fazer em seguida. Pequeno de propósito: quando fica curto, é o sinal para planejar.
• Doing — aquilo em que alguém (uma pessoa ou um agente de IA) está trabalhando agora.
• Done — trabalho concluído. Limpo ou arquivado no fim de uma sprint.

Como montar um quadro Scrumban?

1. Crie as quatro colunas: Backlog, Todo, Doing, Done.
2. Coloque no Backlog tudo o que você sabe que existe. Não ordene tudo — ordene o topo.
3. Decida quanto pode estar em Doing ao mesmo tempo. Para uma pessoa, uma ou duas coisas; para um time pequeno, mais ou menos uma por pessoa.
4. Escolha a duração da sprint — uma ou duas semanas — e escreva para ela um objetivo de uma frase. Puxe para Todo só o que serve a esse objetivo.
5. Trabalhe puxando: quando algo em Doing termina, pegue o próximo cartão do topo de Todo. Ninguém empurra trabalho para ninguém.
6. Planeje quando Todo ficar curto, não por calendário. No fim da sprint, veja o que foi feito e o que não foi, e comece a próxima.

Por que o Weft escolhe o Scrumban

O Weft existe porque a maioria dos gerenciadores de tarefas foi moldada para um de dois extremos: ou um app de lista de afazeres solitário (lista infinita, sem cadência) ou uma suíte Agile para cinquenta pessoas (sobrecarga de processo para um fundador de uma pessoa só). O Scrumban fica exatamente no meio — estrutura suficiente para forçar uma entrega semanal ou quinzenal, não tanta que você passe o dia da entrega administrando-a.

Como o Weft implementa isso

• Quatro colunas padrão: Backlog, Todo, Doing, Done. O trabalho em andamento é limitado pelo que espera por você, não por um número em cada coluna. O Guia do Kanban trata uma política explícita de limite do trabalho em andamento como parte da definição de um fluxo de trabalho, para que novos itens só sejam puxados quando houver capacidade livre.
• Uma sprint ativa por vez, com um objetivo opcional. Sprints são opcionais — pule se o Kanban puro servir. O Guia do Scrum define as Sprints como eventos de duração fixa de um mês ou menos, com uma nova Sprint começando logo após o término da anterior.
• Tarefas têm prioridade, estimativa, prazo e um vínculo opcional com uma sprint. Sem épicos, sem workflows, sem campos personalizados.
• O tempo de ciclo começa quando uma tarefa entra em uma coluna com semantic="doing" e termina em "done". Os números saem do uso honesto, não da aritmética de story points.

Scrumban com agentes de IA

É o trabalho puxado que faz o Scrumban funcionar também para agentes de IA. Um agente conectado ao Weft via MCP pega o próximo cartão sozinho: start_task o reivindica, para que um segundo agente não pegue o mesmo cartão, e complete_task o conclui com o que foi feito e as evidências. Quando um agente precisa de uma decisão, ele pergunta a você em vez de chutar — e, enquanto trabalho concluído demais espera por você, os agentes param de começar tarefas novas. É o limite de trabalho em andamento do Kanban, aplicado ao único recurso que não escala: a sua atenção.

Quando o Scrumban não é o método certo

• Você toca vários times Scrum ao mesmo tempo. O Guia do Scrum coloca um Time Scrum em geral com 10 pessoas ou menos e diz que produtos maiores devem ser organizados em vários Times Scrum que compartilham um único Product Goal e um único Product Backlog. Relatórios em nível de programa, velocidade compartilhada, dependências entre times — o Scrum completo no Jira se justifica. O Nexus Guide foi escrito para essa situação: vários Times Scrum trabalhando a partir de um único Product Backlog, com práticas extras para expor e resolver dependências entre times.
• Você faz suporte puro / operação contínua. Não precisa de cadência de sprint — Kanban puro ou um sistema de tickets serve melhor.
• Você precisa de gráficos de Gantt e cronogramas. O Scrumban é focado em sprints, não em grafos de dependências.

Perguntas sobre Scrumban