O que é Scrumban e como combinar Scrum e Kanban na equipe

O que é Scrumban? É o nome dado à combinação de Scrum e Kanban numa mesma equipe. Na forma mais comum, o time mantém as Sprints e os eventos do Scrum e acrescenta práticas de fluxo do Kanban: um quadro com o fluxo de trabalho explícito, limite de trabalho em andamento e medidas como tempo de ciclo e vazão. A ideia é ganhar previsibilidade sem perder a cadência de planejamento e revisão.

O problema é que a palavra não tem dono nem guia oficial. Uma equipe diz que faz Scrumban porque tirou a Sprint e ficou só com a reunião diária; outra, porque pôs limites de WIP no quadro da Sprint. São coisas muito diferentes. Antes de adotar o nome, vale entender de onde ele vem, quais combinações funcionam e quais são só Scrum ou Kanban mal feitos.

Este artigo parte do princípio de que você conhece o básico dos dois. Se precisa da comparação lado a lado, veja Kanban ou Scrum: diferenças e qual escolher.

O que é Scrumban e de onde vem o termo

O termo é atribuído a Corey Ladas, que escreveu sobre o uso de sistemas Kanban por equipes de desenvolvimento de software. Na proposta original, o Scrumban era um caminho de transição: equipes que usavam Scrum introduziam aos poucos práticas de fluxo e sistema puxado até chegar a um Kanban mais maduro. Não era, portanto, uma mistura definitiva dos dois.

Com o tempo, o uso popular mudou. Hoje "Scrumban" costuma designar qualquer abordagem híbrida entre Scrum e Kanban. Como não existe um documento que defina o Scrumban, cada equipe precisa deixar explícito o que pegou de cada lado. Sem isso, o nome vira desculpa para abandonar as partes difíceis dos dois métodos.

Scrum com Kanban: o que dizem as referências

Duas referências ajudam a combinar sem inventar regras:

• O Guia do Scrum define Sprints de duração fixa, os eventos (Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective), as responsabilidades (Product Owner, Scrum Master e Developers) e os artefatos. A explicação completa está em o que é Scrum.
• O guia de Kanban para times Scrum, mantido pela Scrum.org e desenvolvido por membros da comunidade Scrum com líderes da comunidade Kanban. Ele trata o Kanban como estratégia para otimizar o fluxo e deixa claro que não substitui nenhuma parte do Guia do Scrum: as práticas de fluxo se somam às responsabilidades, aos eventos e aos artefatos existentes.

O guia da Scrum.org reúne práticas como visualizar o fluxo de trabalho, limitar o trabalho em andamento, gerenciar ativamente os itens em andamento e inspecionar e adaptar a definição de fluxo de trabalho do time, além de quatro medidas de fluxo: trabalho em andamento, tempo de ciclo, idade do item e vazão. São as mesmas medidas do Kanban Guide, explicadas no guia o que é Kanban.

Três formas de combinar Scrum e Kanban

Na prática, o que se chama de Scrumban cabe em três desenhos. Escolha um e diga qual é.

O primeiro desenho é Scrum de verdade: nada do Guia do Scrum foi retirado. O terceiro é Kanban de verdade: as reuniões existem porque a equipe decidiu tê-las, não porque o método obriga. O segundo é uma fase, e deve ter começo e fim. O problema aparece quando uma equipe fica no meio do caminho sem saber em qual dos três está.

Como montar um Scrumban em seis passos

O roteiro abaixo segue o primeiro desenho, que é o mais seguro para quem já usa Scrum.

1. Escreva a definição de fluxo de trabalho. O que é um item (uma história, uma correção), quando ele começa, quando termina e por quais estados passa. Isso vira as colunas do quadro.
2. Defina limites de WIP por estado ou para o quadro todo. Comece com o número de itens que a equipe costuma ter em andamento e reduza aos poucos. O raciocínio para escolher está em limites de WIP no Kanban.
3. Registre datas de início e fim de cada item. É o que permite calcular tempo de ciclo, idade e vazão sem planilha paralela.
4. Use a vazão na Sprint Planning. Em vez de discutir só estimativas, olhe quantos itens a equipe terminou nas últimas Sprints para decidir quanto cabe na próxima.
5. Mude o foco da Daily Scrum para o fluxo. Comece pelos itens mais velhos e pelos bloqueados, da direita para a esquerda do quadro. A pergunta é "o que falta para terminar este item?".
6. Leve dados de fluxo para a Retrospective. Tempo de ciclo que cresce, itens que estouraram a expectativa de prazo e filas que se formam viram assunto de melhoria, com fatos.

Exemplo ilustrativo

Imagine a equipe de sistemas de um órgão público que, ao mesmo tempo, desenvolve um novo módulo de atendimento e corrige falhas do sistema em produção. Com Scrum puro, as correções urgentes quebravam a Sprint toda semana. A equipe manteve as Sprints de duas semanas para o módulo novo e criou no mesmo quadro uma raia para correções, com limite de dois itens em andamento e uma política explícita: urgência de produção entra a qualquer momento, desde que haja vaga na raia. Na Sprint Planning, a capacidade reservada para correções passou a vir da vazão histórica dessa raia. O compromisso com a Meta da Sprint ficou mais realista, e as correções deixaram de ser surpresa.

Velocidade ou vazão: qual métrica usar

Muitas equipes Scrum medem velocidade, a soma de pontos de história concluídos por Sprint. É uma prática comum, mas não faz parte do Guia do Scrum. Ao combinar com Kanban, surge a dúvida de qual medida manter.

A vazão (throughput) conta itens terminados por período, sem pontos. Ela funciona bem quando os itens têm tamanho parecido, o que o próprio fluxo incentiva: itens grandes travam o quadro e acabam sendo quebrados. Junto com o tempo de ciclo, a vazão permite prever entregas com probabilidade, sem rodadas de estimativa.

Não há regra que proíba usar as duas. O cuidado é não criar duas versões da verdade: se a equipe usa vazão para planejar, a velocidade não deve ser usada para cobrar desempenho, e vice-versa.

Desafios e erros comuns ao combinar Scrum e Kanban

• Chamar de Scrumban o abandono de eventos. Tirar a Sprint Review e a Retrospective e manter a Daily não é combinação: é perder a inspeção e a adaptação.
• Quadro sem limite. Um quadro de Sprint com colunas e sem WIP continua sendo uma lista de tarefas.
• Dois quadros para o mesmo trabalho. Um para o Scrum e outro para o Kanban duplica atualização e divide a atenção. O fluxo deve estar num lugar só.
• Medir pessoas com dados de fluxo. Tempo de ciclo e vazão medem o sistema. Usá-los para ranquear indivíduos destrói a confiança nos números.
• Não registrar a decisão. Se a equipe não escreve o que pegou de cada método, cada membro novo vai entender o "Scrumban" de um jeito.
• Mudança cultural ignorada. Limitar o WIP exige que as pessoas parem de começar trabalho novo e ajudem a terminar o dos colegas. Sem apoio da liderança para isso, o limite é furado na primeira semana.

Quando o Scrumban faz sentido (e quando não faz)

Faz sentido quando a equipe tem um produto com metas de médio prazo e, ao mesmo tempo, demanda imprevisível, como sustentação ou suporte; quando as Sprints vivem sendo interrompidas; ou quando o time entrega, mas não consegue prever quando. Também é útil como fase de transição para quem quer sair do Scrum para o Kanban sem ruptura.

Faz menos sentido quando a equipe ainda não domina o básico de nenhum dos dois. Nesse caso, comece por um método puro, aprenda as regras e só depois combine. Se a dúvida é mais ampla, sobre misturar ágil com planejamento preditivo num projeto inteiro (com cronograma, marcos e contratos), o tema é outro: veja o modelo híbrido de gestão de projetos.

Próximo passo para a sua equipe

Na próxima Retrospective, desenhe com a equipe a definição de fluxo de trabalho atual, coloque um limite de WIP no quadro da Sprint e comece a anotar datas de início e fim dos itens. Depois de duas ou três Sprints, compare a vazão e o tempo de ciclo com o que vocês prometiam na Sprint Planning. Para dominar o lado Kanban dessa combinação, com limites, métricas e cadências aplicados a projetos, conheça o curso Método Kanban, preparatório CKMS da Projeto Diário.