Scrumban: Combinando Scrum e Kanban

Scrumban é o resultado de parar de forçar uma escolha entre Scrum e Kanban. Equipes que precisam de planejamento estruturado, mas não podem se dar ao luxo de sprints rígidos, recorrem ao scrumban primeiro.

O Que É Scrumban?

Scrumban é um framework ágil híbrido que sobrepõe a mecânica de fluxo contínuo do Kanban à disciplina de planejamento do Scrum. O trabalho se move por um quadro baseado em pull com limites de Work in Progress (WIP), mas os eventos de planejamento acontecem sob demanda em vez de seguir um relógio fixo de sprint.

Corey Ladas cunhou o termo em um ensaio de 2008 e depois o expandiu em seu livro Scrumban: Essays on Kanban Systems for Lean Software Development. Seu argumento central: o Scrum é uma boa estrutura de apoio para equipes novas no ágil, mas à medida que as equipes amadurecem, elas devem eliminar as cerimônias que não agregam valor e manter as que agregam. O modelo de fluxo do Kanban preenche essas lacunas. O resultado é um framework flexível o suficiente para trabalho de manutenção, filas de suporte e operações de marketing, nenhum dos quais se encaixa perfeitamente em sprints de duas semanas.

Principais fatos

• O 17º State of Agile Report (2023) constatou que 9% dos entrevistados usavam um híbrido Scrum/Kanban como abordagem principal de entrega, alta em relação a 6% dois anos antes.
• Equipes que implementam limites de WIP junto com um sistema pull normalmente veem reduções de 20-40% no tempo de ciclo, segundo dados de melhoria de fluxo citados em Principles of Product Development Flow de Donald Reinertsen (2009).
• O scrumban mantém eventos de planejamento, mas os dispara pelo tamanho da fila, não pelo calendário, então o esforço de planejamento permanece proporcional ao volume real de trabalho.

Scrum vs Kanban vs Scrumban

Os três frameworks compartilham um quadro e um backlog, mas divergem rapidamente em cadência, papéis e como o trabalho entra no sistema.

Se sua equipe já roda Scrum mas fica flexibilizando as regras do sprint para lidar com pedidos urgentes, você já está no meio do caminho para o scrumban. E se você roda Kanban mas percebe que nunca para para refletir ou planejar, o modelo estruturado-quando-necessário do scrumban dá a você um motivo para pausar.

Como Funciona o Scrumban

A mecânica do scrumban se apoia em quatro ideias interligadas.

Sistema pull. O trabalho não é empurrado para os engenheiros. Ele é puxado. Quando alguém termina uma tarefa, essa pessoa puxa o próximo item de uma fila pronta para sua coluna. Isso evita que o trabalho se acumule na raia de uma única pessoa e torna os gargalos visíveis imediatamente.

Limites de WIP. Cada coluna do quadro carrega uma quantidade máxima. A coluna Doing pode conter no máximo três cartões de uma vez. Quando a coluna está cheia, a equipe foca em terminar antes de começar qualquer coisa nova. Os limites de WIP são a alavanca mais poderosa para reduzir o tempo de ciclo em qualquer sistema derivado do kanban.

Fila pronta. Entre o backlog e as colunas de trabalho ativo fica uma fila pronta, um pequeno buffer de itens refinados e priorizados que estão genuinamente prontos para serem puxados. A fila pronta desacopla o planejamento da execução. O planejamento pode acontecer em um bloco focado, e depois a equipe puxa da fila à vontade sem precisar de um planejador na sala.

Gatilho de planejamento sob demanda. Em vez de planejar a cada duas semanas independentemente do que aconteça, o scrumban dispara um evento de planejamento quando a fila pronta cai abaixo de um limite definido, digamos dois itens por desenvolvedor. Isso significa que o esforço de planejamento escala com a necessidade real. Semanas tranquilas recebem uma reposição rápida; semanas cheias podem não precisar de planejamento algum.

Um cumulative flow diagram é a ferramenta natural de acompanhamento para o scrumban porque visualiza tamanhos de fila, WIP e throughput em uma única visão. Se uma faixa começa a se alargar, o trabalho está se acumulando mais rápido do que está sendo concluído.

Benefícios do Scrumban

Fluxo sem caos. O modelo de fluxo contínuo do Kanban mantém o trabalho em movimento. O scrumban adiciona estrutura suficiente para impedir que o backlog se transforme em um cemitério de tickets intocados.

Planejamento nos seus termos. Equipes que sofrem com cerimônias de sprint planning que tomam o dia inteiro para duas horas de decisões reais vão notar a diferença imediatamente. O planejamento acontece quando a fila precisa ser reabastecida, não porque o calendário manda.

Menos overhead para equipes estáveis. Assim que uma equipe sabe o que está fazendo, as cerimônias do Scrum que faziam sentido durante o período inicial começam a parecer redundantes. O scrumban permite que as equipes abandonem o que não serve e mantenham o que serve.

Lida com tipos mistos de trabalho. A maioria das equipes reais lida tanto com trabalho planejado (novas features, projetos) quanto com trabalho não planejado (bugs, pedidos, incidentes). O Scrum tem dificuldade com trabalho não planejado porque isso interrompe o sprint. O scrumban absorve isso porque o quadro sempre tem espaço para puxar novos itens para a fila pronta fora do ciclo normal de refinamento.

Visibilidade. O quadro permanece ativo o tempo todo. Qualquer pessoa pode ver o que está em andamento, o que está bloqueado e o quão perto a fila pronta está de disparar o planejamento. Não há espera por uma sprint review para saber o estado do sistema.

Onde o Scrumban Fica Aquém

O scrumban não é uma solução universal. Ele traz seus próprios modos de falha.

Sem papéis significa sem responsabilização. Os papéis definidos do Scrum existem porque alguém precisa ser dono do backlog, alguém precisa facilitar e alguém precisa proteger a equipe do scope creep. O scrumban elimina esses papéis por padrão. Equipes que pulam essa estrutura frequentemente acabam com um backlog desrefinado, reuniões de planejamento para as quais ninguém se prepara e um quadro que ninguém atualiza.

Limites de WIP exigem disciplina. Na primeira vez que um gestor pede à equipe para "só adicionar mais uma coisa", o limite de WIP é discretamente ampliado. Assim que os limites viram sugestões, a mecânica de fluxo entra em colapso. O scrumban só funciona se a equipe tratar os limites de WIP como restrições rígidas.

Não ideal para trabalho de descoberta grande e complexo. Se você está construindo algo genuinamente desconhecido, o ritmo de sprint do Scrum força a reflexão e o planejamento que o trabalho exploratório precisa. O planejamento sob demanda do scrumban pode deixar as equipes irem longe demais sem parar para perguntar se estão construindo a coisa certa.

Difícil de medir velocity. Como não há sprints fixos, as métricas tradicionais de velocity in agile não se aplicam diretamente. As equipes trocam para throughput (itens concluídos por semana) e tempo de ciclo. Isso é uma medida melhor na maioria dos casos, mas exige uma mudança de mentalidade.

Como Implementar o Scrumban

Passo 1: Comece a partir do seu quadro atual

Não redesenhe tudo de uma vez. Seja vindo do Scrum ou do Kanban, mantenha suas colunas e formato de cartão existentes. A primeira mudança é invisível: você está passando de uma mentalidade de push (atribuir trabalho às pessoas) para uma mentalidade de pull (deixar as pessoas puxarem da fila quando estiverem prontas).

Passo 2: Adicione limites de WIP às colunas ativas

Escolha um número conservador para cada coluna em andamento, tipicamente um a dois por membro da equipe. Você vai ajustar depois de uma ou duas semanas. O objetivo não é escolher o número perfeito, é tornar os problemas de fluxo visíveis.

Passo 3: Crie uma fila pronta

Adicione uma coluna "Ready" entre seu backlog e sua primeira coluna ativa. Os itens só se movem para Ready quando estão refinados: definidos, estimados e genuinamente acionáveis. Essa é sua saída de planejamento. A equipe puxa de Ready livremente sem precisar de um planejador presente.

Passo 4: Defina um limite de gatilho de planejamento

Decida até que ponto a fila pronta pode cair antes de você rodar uma sessão de planejamento. Um ponto de partida comum: planejar quando Ready cair abaixo de um suprimento de dois dias. Anote isso. O gatilho deve ser um número real, não "quando parecer baixo".

Passo 5: Rode retrospectivas leves

Mesmo sem sprints fixos, as equipes precisam parar e perguntar o que está funcionando. Agende uma retrospectiva curta a cada duas a quatro semanas, ou após um número definido de itens entregues. Mantenha-a curta, de 30 a 45 minutos, e focada no fluxo: o que nos atrasou, o que ajudou e qual única coisa mudaríamos na próxima vez.

Depois de alguns ciclos você terá dados reais de throughput. Use-os para refinar os limites de WIP, ajustar o gatilho de planejamento e identificar quais tipos de trabalho passam pelo quadro mais rápido. Esse é o ciclo de melhoria contínua no centro da agile methodology.

Exemplos de Scrumban por Tipo de Equipe

Melhores Práticas

Mantenha o quadro honesto. Atualize o status do cartão no momento em que ele muda, não no standup, não no fim do dia. Um quadro desatualizado é pior que nenhum quadro porque cria uma falsa confiança.

Trate os limites de WIP como um contrato da equipe. Combinem-nos juntos, escrevam-nos no quadro e cobrem uns dos outros. Quando alguém quiser exceder o limite, isso deve ser uma conversa, não uma decisão unilateral.

Separe trabalho urgente de trabalho planejado. Adicione uma pequena linha "Fast Lane" no quadro para emergências genuínas. Limite-a a um item por vez. Isso dá aos incidentes um caminho sem explodir o fluxo principal.

Visualize o trabalho bloqueado. Use uma sinalização ou etiqueta de cor para cartões bloqueados em vez de simplesmente deixá-los em andamento. Trabalho bloqueado sentado quietamente dentro de um limite de WIP é desperdício invisível.

Meça o tempo de ciclo, não a velocity. Acompanhe quanto tempo os itens passam entre Ready e Done. O tempo de ciclo mostra o quão previsível é sua entrega. Melhorá-lo é o objetivo principal do sistema pull.

Retome periodicamente o que é Scrum e o que é Kanban. O scrumban toma emprestado dos dois, e quando algo não está funcionando ajuda voltar aos princípios de origem. Muitas vezes a resposta já está lá.

Se sua equipe está explorando frameworks mais amplos para escalar, o Scaled Agile Framework (SAFe) aborda tensões parecidas em nível de portfólio. E para equipes que querem ainda menos cerimônia que o scrumban, a Extreme Programming (XP) vai em uma direção diferente: mais prática de engenharia, menos estrutura de processo.

Perguntas Frequentes

O Scrumban tem sprints?

Não por padrão. O scrumban substitui sprints fixos por planejamento sob demanda disparado pelo tamanho da fila. Dito isso, algumas equipes mantêm uma cadência solta de planejamento a cada duas semanas como um mecanismo forçador, enquanto usam a mecânica de fluxo para o trabalho do dia a dia. O framework é flexível o suficiente para incluir sprints se isso servir à equipe.

Existem papéis definidos no Scrumban?

Não. O scrumban elimina os papéis de Product Owner, Scrum Master e Dev Team que o Scrum exige. As equipes decidem por conta própria quem é dono do backlog, quem facilita o planejamento e quem mantém o quadro. Muitas mantêm um papel leve de product owner porque alguém ainda precisa priorizar. Mas o framework não exige isso.

O Scrumban é bom para equipes de manutenção?

É um dos encaixes mais adequados. O trabalho de manutenção é imprevisível, vem em tamanhos variados e não se encaixa bem em ciclos de sprint planning. O sistema pull e o planejamento sob demanda permitem que equipes de manutenção lidem com o que aparecer sem negociar constantemente o escopo contra um limite de sprint.

Como o Scrumban é diferente de simplesmente "fazer Kanban"?

A principal diferença é estrutura. O Kanban puro não tem cerimônias obrigatórias, gatilhos de planejamento ou um ciclo de reflexão embutido. O scrumban adiciona uma fila pronta, um limite de gatilho de planejamento e retrospectivas opcionais. É Kanban com barreiras de proteção para equipes que acharam que o fluxo puro deixava coisas demais ao acaso.

Quais métricas as equipes de Scrumban devem acompanhar?

Tempo de ciclo (tempo de Ready até Done), throughput (itens concluídos por semana) e tamanho da fila são as três métricas centrais. Um cumulative flow diagram plota as três em uma única visão e torna os gargalos evidentes. Evite acompanhar a velocity a menos que você tenha introduzido sprints, porque a velocity é uma medida baseada em sprint.

O scrumban continua evoluindo à medida que as equipes encontram novas combinações das cerimônias do Scrum e das ferramentas de fluxo do Kanban. A força duradoura do framework vem de uma ideia simples: otimizar o processo para o trabalho real, não o contrário. Comece com seu quadro atual, adicione limites de WIP e observe o que as restrições revelam.

Leitura Relacionada

• O Que É Scrum
• O Que É Kanban
• Scrum vs Kanban
• Limites de WIP
• Cumulative Flow Diagram
• Sprint Planning
• Velocity in Agile
• O Que É Agile Methodology
• Extreme Programming
• Scaled Agile Framework (SAFe)