Scrumban: o híbrido de Scrum e Kanban na prática

O que é Scrumban

Scrumban é um modelo híbrido de gestão de trabalho que combina a cadência e as cerimônias do Scrum com o fluxo contínuo e os limites de trabalho em progresso (WIP) do Kanban. Do Scrum, ele herda o ritmo: ciclos regulares de planejamento, revisão e retrospectiva, que dão previsibilidade e momentos fixos de alinhamento. Do Kanban, herda a mecânica do dia a dia: um quadro visual onde o trabalho flui de coluna em coluna, itens são puxados conforme a capacidade real do time e o WIP limitado impede que tudo comece e nada termine.

O nome surgiu no mundo do desenvolvimento de software, como um caminho de transição de times que saíam do Scrum em direção ao Kanban. Mas, na prática de hoje, Scrumban virou destino final para muitos times — de TI e de fora dela — que perceberam uma verdade incômoda: nem todo trabalho cabe numa sprint fechada, e nem todo time sobrevive sem cadência nenhuma.

A pergunta que o Scrumban responde é simples: "e se o meu time tem os dois tipos de demanda ao mesmo tempo?" Uma parte do trabalho é planejável — projetos, campanhas, melhorias com prazo. Outra parte chega sem avisar — urgências, pedidos de outras áreas, incidentes, "só uma coisinha rápida". Scrum puro sofre com a segunda; Kanban puro deixa a primeira sem ritmo. O híbrido tenta ficar com o melhor dos dois.

Para quem o Scrumban serve (e para quem não serve)

O perfil ideal é o time com demanda mista. Alguns exemplos reais de formato:

• Marketing: a equipe da Renata planeja campanhas com semanas de antecedência (planejável), mas toda semana chega pedido de arte urgente do comercial, ajuste de landing page e resposta a crise nas redes (imprevisível). Sprint fechada quebra toda segunda-feira; Kanban puro faz as campanhas grandes se arrastarem sem prazo.
• RH / People: o time do Jorge toca projetos estruturados — revisão do onboarding, ciclo de avaliação, pesquisa de clima — e ao mesmo tempo atende demandas que não esperam: desligamento delicado, conflito entre áreas, admissão que precisa sair essa semana.
• Times de produto ou engenharia com sustentação: metade da capacidade vai para o roadmap, metade para bugs e chamados. É o caso clássico que fez o Scrumban nascer.
• Jurídico, financeiro, operações: contratos e fechamentos têm calendário; pareceres urgentes e exceções, não.

Se o seu time se parece com algum desses, o híbrido merece um teste. Por outro lado, Scrumban não é a resposta para tudo:

• Se o trabalho é quase todo planejável e o time consegue proteger o escopo por duas semanas, o Scrum tradicional provavelmente entrega mais foco com menos regra nova.
• Se o trabalho é quase todo reativo (suporte, atendimento, triagem), o Kanban puro com boas políticas de fila resolve — a cadência de sprint viraria teatro.
• Se o time ainda não domina nem Scrum nem Kanban, começar pelo híbrido é arriscado: você combina duas coisas que ninguém entende. Antes de misturar, vale entender as diferenças entre Kanban e Scrum em separado.

O que você pega de cada lado

O Scrumban bem montado não é "um pouco de cada, do jeito que der". Ele pega peças específicas de cada método, com função clara.

Do Scrum: a cadência e as cerimônias

• Ciclo fixo de 1 ou 2 semanas. Não como compromisso rígido de escopo, mas como batida do time: a cada ciclo, todo mundo para, prioriza e alinha.
• Planning enxuta. No começo do ciclo, o time olha o backlog priorizado e responde: "o que é mais importante puxar nas próximas duas semanas?" Diferente da planning clássica, ninguém promete entregar uma lista fechada — o time define uma meta do ciclo (a campanha X no ar, o ciclo de avaliação configurado) e uma ordem de prioridade.
• Review e retrospectiva no fim do ciclo. A review mostra o que foi concluído para quem interessa; a retrospectiva cuida da melhoria do processo — e no Scrumban ela é ainda mais vital, porque é onde o time ajusta limites de WIP, políticas de urgência e colunas do quadro.
• Daily curta, olhando o quadro da direita para a esquerda: primeiro o que está quase pronto, depois o que está travado.

Do Kanban: o fluxo e o WIP

• Quadro visual com colunas que espelham o processo real do time — não as três colunas genéricas, mas as etapas de verdade, incluindo esperas por terceiros. Se precisar de referência, veja como definir as colunas do Kanban.
• Limites de WIP por coluna ou por pessoa. É a regra que muda tudo: ninguém puxa item novo se a coluna está no limite. Quando algo trava, o time termina antes de começar. Se o conceito é novo para você, comece por limites de WIP no Kanban.
• Sistema puxado. O trabalho não é empurrado para as pessoas na planning; cada um puxa o próximo item da fila priorizada quando libera capacidade.
• Política explícita para urgências. Em vez de urgência quebrar a sprint, existe uma raia de expresso (ou um limite tipo "no máximo 1 urgência em andamento por vez") com critério escrito do que merece furar a fila. A urgência entra pelo processo, não por cima dele.

No TeamBOX, esse arranjo cabe naturalmente: o board da sprint tem colunas que incluem estados de espera (como "Dependência externa" e "Teste"), e a cadência de sprints com calendário e termômetro dá o ritmo — enquanto o fluxo dos cards, dia a dia, funciona como um Kanban puxado.

Como montar o Scrumban do seu time em 6 passos

1. Desenhe o fluxo real antes de qualquer regra. Reúna o time e mapeie por quais etapas um item passa de verdade, do pedido à entrega — incluindo as esperas ("aguardando aprovação do diretor", "com a agência"). Esse desenho vira as colunas do quadro.

2. Defina a cadência. Uma ou duas semanas, com dia e hora fixos para planning (início) e review + retro (fim). Duas semanas é um bom padrão; uma semana funciona para times com demanda muito volátil.

3. Estabeleça limites de WIP e comece apertado. Uma regra de bolso: WIP total próximo do número de pessoas do time, ou até menos. Um time de 5 pessoas com 14 itens "em andamento" não está trabalhando mais — está terminando menos. O limite vai doer nas primeiras semanas; é sinal de que está funcionando.

4. Escreva a política de urgência em uma frase. Exemplo do time de marketing da Renata: "Fura a fila o que tem impacto direto em receita ou reputação nesta semana; todo o resto entra no topo do backlog e espera a próxima planning." Sem critério escrito, tudo vira urgente — e aí você não tem Scrumban, tem pânico com post-its.

5. Rode a planning como priorização, não como promessa. Ordene o backlog, defina a meta do ciclo, confirme que os primeiros itens estão claros o suficiente para serem puxados (se o time já usa critérios de aceite, mantenha — eles continuam valendo no híbrido).

6. Use a retro para calibrar o sistema. A cada ciclo, três perguntas: os limites de WIP estão certos? A política de urgência foi respeitada? Quanto da capacidade foi consumida por trabalho não planejado? Essa última resposta, acompanhada ao longo dos ciclos, é o dado mais valioso do Scrumban — ela mostra se o time precisa reservar mais ou menos espaço para o imprevisto.

O que abandonar de cada lado (sem culpa)

A força do híbrido está tanto no que você adota quanto no que você corta. Do Scrum, o Scrumban tipicamente abandona:

• O compromisso de escopo da sprint. A meta do ciclo existe, mas a lista fechada de itens prometidos, não. Isso elimina o drama recorrente de escopo que muda no meio da sprint — mudar deixa de ser exceção e vira parte do sistema.
• A estimativa detalhada de tudo. Muitos times de Scrumban param de estimar item a item e passam a medir o tempo real que os itens levam para atravessar o quadro (lead time), que costuma prever melhor. Estimar só o que é grande e incerto é um meio-termo saudável.
• A velocity como métrica central. Sem escopo fechado, somar pontos por sprint perde o sentido; vazão (itens concluídos por ciclo) e lead time contam a história melhor.

Do Kanban, abandona-se:

• O fluxo sem ritmo. Cerimônias "quando precisar" viram cerimônias "nunca". A cadência fixa é inegociável no Scrumban — é ela que separa o híbrido do improviso.
• A ausência de meta. Kanban puro otimiza o fluxo, mas não diz para onde o time está indo. A meta do ciclo, herdada do Scrum, dá direção e critério de prioridade.
• A entrada de trabalho a qualquer momento sem filtro. Itens novos entram no backlog e esperam a priorização — salvo os que passam pela política de urgência.

Sinais de que o híbrido virou bagunça

Scrumban tem um risco específico: como ele já nasce flexível, é fácil usá-lo como desculpa para não seguir regra nenhuma. Fique atento a estes sintomas:

1. Tudo é urgente. Se metade dos itens em andamento entrou pela raia de expresso, a política de urgência morreu. Ou o critério está frouxo, ou ninguém tem coragem de dizer não.
2. O WIP é decorativo. O limite está escrito no topo da coluna e a coluna tem o dobro de cards. Limite ignorado é pior que limite inexistente: ensina o time que as regras do quadro são sugestão.
3. As cerimônias foram sumindo. Primeiro pulou-se uma retro "porque a semana estava corrida", depois a review virou um e-mail, depois a planning virou o gestor distribuindo tarefas no privado. Sem cadência, o que sobrou é um quadro Kanban mal cuidado.
4. Ninguém sabe o que é prioridade. Na daily, cada pessoa escolhe o que puxar por gosto pessoal, não pela ordem do backlog. O sistema puxado pressupõe fila priorizada; sem ela, é autosserviço.
5. Itens envelhecem sem dono. Cards parados há semanas em "aguardando" que ninguém cobra são o sinal clássico de gargalo no fluxo sendo ignorado — e o Scrumban, com retro quinzenal, não tem desculpa para não enxergá-los.
6. O híbrido muda toda semana. Ajustar o processo na retro é saudável; reinventar as regras a cada conversa de corredor, não. Mudança de política entra em vigor no ciclo seguinte, documentada, para todo mundo junto.

Se três ou mais desses sinais aparecem ao mesmo tempo, o remédio não é trocar de método de novo — é voltar ao básico: republicar as regras (colunas, limites, política de urgência), retomar a cadência das cerimônias e sustentar isso por três ciclos antes de mexer em qualquer outra coisa.

Checklist para começar na segunda-feira

• Fluxo real mapeado com o time → colunas do quadro (incluindo esperas)
• Cadência definida: ciclo de 1 ou 2 semanas, com planning, review e retro no calendário de todos
• Limites de WIP escritos no quadro (comece apertado: perto de 1 item por pessoa)
• Política de urgência em uma frase, visível para o time e para quem pede trabalho
• Backlog único e priorizado — só se puxa item do topo
• Meta do ciclo definida na primeira planning (uma frase, não uma lista)
• Combinado de medição: vazão por ciclo e percentual de trabalho não planejado
• Primeira retro agendada com pauta fixa: WIP, urgências e envelhecimento dos cards

Rode três ciclos sem mudar as regras no meio. No fim do terceiro, o time terá dados de verdade — quantos itens atravessam o quadro por ciclo, quanto do esforço vai para o imprevisto — e aí sim as calibragens deixam de ser opinião e viram decisão.