Kanban ou Scrum: qual usar no seu time?

Kanban e Scrum: o que cada um é, em uma definição honesta

Scrum é um método de trabalho em que o time entrega em ciclos curtos e fixos chamados sprints (normalmente de uma a quatro semanas). Antes de cada ciclo, o time planeja o que cabe nele; durante, sincroniza diariamente; no fim, mostra o que ficou pronto e discute como melhorar. Scrum tem papéis definidos (Product Owner, Scrum Master e o time de desenvolvimento do produto — que pode ser qualquer "produto": uma campanha, um processo de RH, um software) e cerimônias com hora marcada.

Kanban é um método de gestão de fluxo contínuo: o trabalho é visualizado em um quadro com colunas (por exemplo, "A fazer → Em andamento → Concluído"), e o time limita quantos itens podem estar em andamento ao mesmo tempo (o famoso limite de WIP, work in progress). Não há sprint, não há papéis obrigatórios, não há cerimônias fixas: quando um item termina, o próximo mais importante entra. O controle vem do fluxo, não do calendário.

A frase que resume a diferença: Scrum controla o trabalho pelo tempo; Kanban controla o trabalho pelo fluxo. No Scrum, você pergunta "o que cabe nas próximas duas semanas?". No Kanban, você pergunta "qual é a próxima coisa mais importante, e temos capacidade para puxá-la agora?". Os dois são métodos ágeis, os dois usam quadros visuais, os dois funcionam fora de TI — mas partem de lógicas diferentes, e escolher errado gera atrito desnecessário.

Se você ainda está se familiarizando com cada método isoladamente, vale ler o guia de Kanban para gestão de times e o guia completo do método Scrum — este artigo aqui é sobre a decisão entre eles.

As diferenças que importam na prática

Muita comparação de Kanban vs Scrum se perde em detalhe teórico. Na prática, três diferenças decidem qual método vai servir ao seu time.

1. Cadência: sprint fechada × fluxo aberto

No Scrum, a sprint é um compromisso de escopo dentro de um tempo fixo. O time planeja, fecha a porta e protege aquele pacote de entregas de interrupções. Isso cria ritmo, previsibilidade e um momento natural de celebração e aprendizado a cada ciclo — se quiser entender melhor essa mecânica, veja o que é uma sprint.

No Kanban, não existe "fechar a porta". O quadro está sempre aberto: chegou demanda urgente, ela entra na fila e será puxada quando houver capacidade. Não há começo nem fim de ciclo — há um fluxo que você quer manter saudável e rápido.

Consequência prática: se a sua demanda muda todo dia (um chamado urgente do cliente, um pedido do jurídico, uma pauta que caiu de paraquedas), a sprint do Scrum vira uma promessa quebrada semanalmente — e time que quebra promessa toda semana para de acreditar no método. Nesse cenário, Kanban sofre menos, porque nunca prometeu escopo fixo.

2. Papéis: definidos × opcionais

Scrum prescreve papéis: alguém prioriza e responde pelo valor (Product Owner), alguém cuida do processo e remove impedimentos (Scrum Master), e o time executa. Em times fora de TI, esses papéis aparecem com outros nomes — a coordenadora de marketing que prioriza o backlog de campanhas está fazendo papel de PO, mesmo sem o crachá.

Kanban não exige papel nenhum. Você pode adotá-lo amanhã, com o time que tem, sem nomear ninguém. Isso é uma força (barreira de entrada baixíssima) e uma fraqueza (sem dono claro da priorização, o quadro vira um depósito de post-its onde tudo é urgente e nada anda).

3. Métricas: velocidade × tempo de fluxo

Scrum mede quanto o time entrega por ciclo — pontos ou itens concluídos por sprint — e acompanha o progresso dentro do ciclo com o gráfico de burndown. Isso permite responder "quanto conseguimos assumir na próxima sprint?" com base em histórico, não em achismo. As métricas de sprint merecem um artigo próprio, mas a lógica é essa: previsibilidade por ciclo.

Kanban mede quanto tempo um item leva para atravessar o quadro (lead time e cycle time) e quantos itens saem por semana (vazão, ou throughput). A pergunta que ele responde é outra: "se eu colocar este pedido na fila hoje, quando ele fica pronto?".

Repare que as métricas revelam a alma de cada método: Scrum responde perguntas de planejamento ("o que cabe no ciclo?"); Kanban responde perguntas de atendimento ("quando fica pronto?"). Qual pergunta o seu time mais escuta?

Quando o Kanban brilha

Kanban é a escolha natural quando a demanda chega de fora, de forma contínua e imprevisível, e o valor está em atender rápido e com fluidez:

• Suporte e atendimento ao cliente. Ninguém planeja os chamados da próxima quinzena — eles chegam quando chegam. O time da Renata, que cuida do suporte de uma fintech, roda um quadro com limite de 3 chamados em andamento por pessoa: quando alguém tenta abrir um quarto, o limite força a conversa certa ("o que está travado e por quê?").
• Jurídico, financeiro e operações. Contratos para revisar, notas para conciliar, pedidos internos: trabalho de fila, com prioridades que mudam. Sprint aqui só adicionaria burocracia.
• Design e conteúdo sob demanda. Um estúdio interno que atende várias áreas da empresa vive de pedidos que não param de chegar; o quadro Kanban dá visibilidade da fila para quem pede e protege o time do "só uma artezinha rápida".
• Times em fase de descoberta do próprio processo. Kanban começa mapeando o fluxo que já existe, sem impor nada. Para um time que nunca teve método nenhum, é o primeiro passo menos traumático.

O sinal clássico de que Kanban é o caminho: quando você imagina o time planejando duas semanas de trabalho e a reação honesta é "não faz sentido, a gente não controla o que vai chegar".

Quando o Scrum brilha

Scrum é a escolha natural quando o time constrói algo que pode ser planejado em blocos e a previsibilidade vale mais que a flexibilidade total:

• Times de produto e engenharia. O caso mais conhecido: funcionalidades quebradas em histórias, planejadas por sprint, com review para colher feedback cedo.
• Marketing orientado a campanhas. O time do Caio planeja sprints quinzenais: cada ciclo entrega peças de uma campanha, e a review vira o momento de mostrar resultados parciais para as áreas parceiras. A cadência protege o time do "pedido do dia" e cria ritmo de entrega visível.
• RH em modo projeto. Redesenhar o onboarding, implantar um ciclo de avaliação, lançar um programa de liderança: iniciativas com escopo definível, perfeitas para quebrar em sprints com metas claras — o movimento de levar Scrum para fora da TI tem crescido justamente por isso.
• Times que precisam reconquistar confiança. Quando a área tem fama de "não entrega", a sprint funciona como contrato público: prometemos isto, em duas semanas mostramos. O ciclo curto de promessa-entrega-demonstração reconstrói credibilidade como nenhum quadro de fluxo consegue.

O sinal clássico de que Scrum é o caminho: quando o problema do time não é a chegada de demanda, e sim falta de ritmo, de foco e de um momento para mostrar o que ficou pronto.

Scrumban: o híbrido honesto (e quando ele é desculpa)

Na vida real, pouquíssimos times são 100% fluxo ou 100% planejáveis. Quase todo time de produto tem bugs urgentes furando a fila; quase todo time de suporte tem projetos internos de melhoria. Daí nasce o Scrumban: manter a cadência do Scrum e adotar práticas do Kanban dentro dela.

Um arranjo comum e saudável:

• Sprints continuam existindo — com planning, review e retrospectiva, porque o ritmo e os momentos de aprendizado valem ouro.
• O quadro ganha limite de WIP — ninguém abre uma tarefa nova com três em andamento; primeiro termina, depois puxa.
• Uma fatia da capacidade fica reservada para o imprevisto — o time planeja, digamos, 80% da capacidade e deixa o restante para urgências, em vez de fingir que elas não vão acontecer.
• Itens expressos têm uma raia própria — o que é realmente urgente entra por uma faixa especial do quadro, com regra explícita de quando algo merece esse tratamento (senão tudo vira "expresso").

No TeamBOX, esse arranjo é natural: o board da sprint tem colunas que expõem o fluxo real do trabalho — incluindo estados como "Dependência externa" e "Teste", onde os itens costumam empacar —, e o termômetro da sprint avisa o gestor quando o ritmo de entrega descola da meta. Ou seja, você mantém a cadência do Scrum enxergando o fluxo como um bom quadro Kanban exige.

Agora, o alerta: Scrumban também pode ser desculpa. "A gente é híbrido" às vezes significa "a gente faz planning mas não respeita o plano, tem quadro mas não limita WIP, e chama de ágil". Híbrido honesto tem regras explícitas (quanto de capacidade é reservada, o que pode furar fila, qual o limite de WIP). Híbrido desonesto é só bagunça com vocabulário ágil. Se o seu time está no segundo caso, a retrospectiva é o lugar para encarar isso.

Cinco perguntas para decidir

Sente com o time (ou traga para a próxima retro) e respondam juntos:

1. A demanda é previsível o suficiente para planejar duas semanas? Se a resposta for "quase nada do que fazemos hoje foi planejado", comece por Kanban. Se for "sim, na maior parte", Scrum.
2. O que dói mais: interrupção ou falta de ritmo? Interrupção constante quebrando planos → Kanban (ou Scrumban com capacidade reservada). Time sem cadência, entregas que se arrastam sem data → Scrum.
3. Quem responde pela priorização? Se existe (ou pode existir) uma pessoa clara priorizando, Scrum funciona. Se a priorização é distribuída e situacional, Kanban exige menos estrutura.
4. O que os stakeholders perguntam? "Quando fica pronto o meu pedido?" → Kanban e suas métricas de fluxo. "O que vem no próximo ciclo?" → Scrum e seu planejamento por sprint.
5. Qual é a maturidade do time com métodos? Time cru, sem hábito de processo: Kanban primeiro (visualize o fluxo que já existe). Time que já tem disciplina de reunião e combinados: Scrum entrega mais valor de cara.

Três ou mais respostas apontando para o mesmo lado? Comece por ele. Empatou? Comece pelo Kanban — é mais barato de adotar e de abandonar.

Dá para trocar depois (e provavelmente você vai)

Essa é a parte que as comparações raramente dizem: a escolha não é um casamento. Times saudáveis mudam de método quando o trabalho muda de natureza — e o que você construiu não se perde na troca.

O caminho Kanban → Scrum é comum quando o time amadurece: o fluxo está mapeado, os gargalos conhecidos, e agora a dor é previsibilidade ("precisamos nos comprometer com entregas por ciclo"). O quadro vira o board da sprint, a fila vira backlog priorizado, e entra a cadência de planning e review.

O caminho Scrum → Kanban acontece quando a natureza da demanda muda: o produto entrou em modo manutenção, o time virou referência de atendimento interno, e a sprint passou a ser teatro — planeja-se sabendo que metade vai furar. Melhor assumir o fluxo contínuo com honestidade do que manter cerimônias vazias.

E o caminho mais frequente de todos é a convergência gradual: o time de Scrum adota limite de WIP e métricas de fluxo; o time de Kanban adota uma retro quinzenal e uma reunião curta de sincronização diária. Depois de um ou dois anos, os times maduros se parecem bastante entre si — ficam com o que funciona de cada método e largam o resto.

Erros comuns ao escolher (e ao usar) cada método

• Escolher pelo hype, não pela demanda. "Todo mundo usa Scrum" não é argumento. A pergunta é sempre: como a demanda chega no seu time?
• Rodar Scrum sem proteger a sprint. Se qualquer pedido entra no meio do ciclo, você não tem Scrum — tem Kanban com reuniões caras. Ou proteja o escopo, ou assuma o fluxo contínuo.
• Rodar Kanban sem limite de WIP. Quadro sem limite de trabalho em andamento é só um mural bonito. O limite é o que transforma visualização em gestão — sem ele, todo mundo começa tudo e ninguém termina nada.
• Adotar os artefatos e pular as conversas. Board, post-it e gráfico são meios. O valor está nas conversas que eles provocam: priorização explícita, impedimentos ditos em voz alta, aprendizado a cada ciclo. As cerimônias do time existem para isso.
• Tratar a escolha como definitiva. Reavalie a cada trimestre, de preferência na retrospectiva: o método ainda serve à natureza do trabalho? Se a resposta hesitar, experimente ajustar — trocar de método custa muito menos do que insistir no errado por orgulho.