Scrum vs Kanban: Principais Diferenças e Quando Usar Cada Um

Ambos são ágeis. Ambos usam um quadro. Mesmo assim, equipes que confundem Scrum com Kanban acabam com a rigidez de Sprints onde precisavam de fluxo contínuo, ou com a flexibilidade do Kanban onde precisavam de planejamento estruturado. A distinção principal é a cadência: um tem limite de tempo, o outro flui como um rio.

Qual é a diferença entre Scrum e Kanban?

Scrum tem limite de tempo: o trabalho ocorre em Sprints fixos (geralmente de uma a quatro semanas), com papéis definidos e uma cadência de planejamento obrigatória. Kanban é fluxo contínuo: o trabalho avança pelo quadro sem reinicializações rígidas, restringido não pelo tempo, mas pelos limites de Work in Progress (WIP) em cada coluna.

Ambos os frameworks surgiram do pensamento ágil e Lean. Mas seus objetivos divergem. Scrum foi projetado para trabalho de produto imprevisível e com muita descoberta, onde as equipes precisam de loops de feedback estruturados. Kanban, que tem suas raízes no Sistema de Produção Toyota (TPS) dos anos 1940, foi projetado para otimização de fluxo, onde o objetivo é throughput constante e mínimos gargalos, não a velocidade do Sprint.

Fatos-chave

• O Scrum Guide foi codificado pela primeira vez por Jeff Sutherland e Ken Schwaber em 1995 e revisado mais recentemente em 2020. A revisão de 2020 simplificou o framework e substituiu "Development Team" por "Developers."
• O Kanban para trabalho do conhecimento foi formalmente codificado por David J. Anderson em seu livro de 2010 "Kanban: Successful Evolutionary Change for Your Technology Business" (Blue Hole Press), embora suas origens na manufatura remontem ao Sistema de Produção Toyota de Taiichi Ohno nos anos 1940.
• Segundo o 17º Relatório Anual sobre o Estado do Agile (2023), 87% dos entrevistados usam Scrum ou um híbrido de Scrum como método principal, enquanto 56% usam Kanban e 9% usam Scrumban. Muitas equipes relataram usar mais de uma abordagem.

Em resumo: as 10 maiores diferenças

Veja a forma mais rápida de entender como os dois frameworks realmente divergem:

Cadência e planejamento

O Sprint do Scrum não é negociável. A equipe concorda com uma meta, seleciona um conjunto de itens do Backlog e não muda esse escopo no meio do Sprint. Isso cria um mecanismo de força: a cada uma a quatro semanas, a equipe entrega algo, revisa com as partes interessadas e ajusta a direção. É um ritmo em torno do qual você pode planejar.

Kanban não tem Sprint. O trabalho chega, é priorizado e flui pelo quadro conforme a capacidade fica disponível. O planejamento é leve: uma reunião de reabastecimento para reabastecer o topo da fila. Não há compromisso com "o que terminaremos esta semana." O compromisso acontece no nível do item individual, rastreado pelo tempo de ciclo (quanto tempo um item leva do início ao fim?).

Na prática, as equipes Scrum frequentemente lutam com o "teatro do Sprint", em que a cerimônia acontece, mas a meta do Sprint é fictícia. As equipes Kanban frequentemente lutam com o oposto: tudo está em andamento, os limites de WIP são ignorados e o quadro vira um estacionamento. Ambos os problemas são problemas de disciplina, não de framework.

Papéis e cerimônias

Scrum tem três papéis e cinco eventos:

Papéis: Product Owner (é dono do Backlog, define a prioridade), Scrum Master (treina o processo, remove bloqueios), Developers (constroem o produto). Os três são obrigatórios para o Scrum funcionar como projetado.

Eventos: Sprint Planning, Daily Scrum (a reunião de pé de 15 minutos), Sprint Review, Sprint Retrospective e o próprio Sprint. Eles não são opcionais, embora as equipes frequentemente tentem pular a Retrospective.

Kanban não exige nenhum papel. Nenhum Kanban Master, nenhum equivalente ao Product Owner na especificação. As equipes frequentemente têm um gerente de fluxo ou gerente de entrega de serviço na prática, mas essa é uma escolha organizacional, não um requisito do framework. Cadências opcionais incluem reuniões de reabastecimento (preencher a fila), planejamento de entrega, revisões de entrega de serviço e retrospectivas. Nenhuma é obrigatória.

É por isso que Kanban é mais fácil de introduzir em uma equipe existente. Você não está pedindo que as pessoas mudem seus títulos de trabalho. Você está apenas tornando o fluxo de trabalho visível e adicionando limites de WIP.

Métricas: Velocity vs tempo de ciclo

Scrum mede a Velocity: quantos pontos de história (ou unidades similares) a equipe completa por Sprint? A Velocity é útil para o planejamento do Sprint e previsão grosseira de capacidade. Não é útil para prever quando um item específico será entregue.

Kanban mede o tempo de ciclo (quanto tempo um item leva de "iniciado" a "concluído"?) e o throughput (quantos itens a equipe completa por unidade de tempo?). Esses são mais preditivos para entregáveis individuais: se o seu tempo de ciclo médio é de 3 dias com baixa variância, você pode dizer a uma parte interessada "este item provavelmente estará pronto até quinta-feira" com real confiança.

O diagrama de fluxo cumulativo é o gráfico característico do Kanban: ele mostra o volume de trabalho em cada etapa ao longo do tempo, tornando os gargalos visíveis como faixas que se alargam. O gráfico de Burndown do Scrum mostra o trabalho restante em um Sprint. Ambos são úteis; eles estão medindo coisas diferentes.

Quando usar Scrum vs Kanban: uma árvore de decisão

A resposta honesta é: escolha com base em como o seu trabalho realmente chega, não em qual framework soa mais prestigioso.

Use Scrum quando:

• Seu trabalho tem metas de produto descobríveis que se beneficiam de ciclos de descoberta estruturados.
• A equipe pode se comprometer com um escopo de Sprint sem que tudo seja uma "emergência."
• Os loops de aprendizado importam: você entrega algo, aprende com isso e corrige o rumo antes de construir mais.
• As partes interessadas se beneficiam de checkpoints de revisão regulares e previsíveis.
• Você está construindo um produto com um Roadmap, não processando uma fila de tickets.

Use Kanban quando:

• O trabalho chega de forma imprevisível: tickets de suporte, solicitações de operações, trabalho de manutenção.
• A otimização de throughput importa mais do que a Velocity do Sprint.
• A equipe não pode se comprometer com um escopo fixo porque as interrupções fazem parte do trabalho.
• Você quer um ponto de entrada de baixa cerimônia no gerenciamento estruturado de fluxo de trabalho.
• Você está melhorando um processo existente em vez de descobrir um novo produto.

Use Scrumban quando:

• Você superou a rigidez do Scrum, mas ainda quer algum ritmo de planejamento.
• Você tem uma mistura de trabalho de produto planejado e trabalho de suporte não planejado na mesma equipe.
• Seus Sprints estão principalmente renomeando os mesmos tickets, e as Retrospectives não estão produzindo mudanças.

Uma heurística útil: se a estrutura analítica do projeto da sua equipe pode ser definida com duas semanas de antecedência com razoável confiança, o Scrum se encaixa. Se não puder, o Kanban se encaixa melhor. E se o seu gráfico de Gantt é principalmente ficção porque o escopo continua mudando, veja para que serve um gráfico de Gantt antes de se comprometer com qualquer um deles.

Mitos e equívocos comuns

As equipes frequentemente adotam o framework errado porque estão respondendo a um mito em vez de à sua situação real:

• "Kanban não tem regras." Tem menos cerimônias, mas as regras são reais. Limites de WIP não são sugestões. Violá-los sinaliza um problema sistêmico que precisa ser resolvido, não um limite de WIP que precisa ser excluído.
• "Scrum é mais maduro ou profissional." Maturidade é irrelevante. A Netflix usa gerenciamento de fluxo inspirado no Kanban. As equipes de produto de software da Amazon usam abordagens baseadas em Sprint. A ferramenta certa depende do trabalho, não do prestígio.
• "Você não pode misturá-los." Scrumban existe especificamente porque as equipes encontraram valor em combinar elementos de ambos. Os frameworks não são uma religião.
• "Quadros Kanban são quadros Scrum." Um quadro é apenas uma ferramenta de visualização. O quadro Scrum reinicia a cada Sprint e mostra o estado do Sprint. O quadro Kanban é persistente, mostra as etapas do fluxo de trabalho e impõe limites de WIP. Mesmo móvel, sala diferente.
• "Daily standups são Kanban." O Daily Scrum é uma cerimônia do Scrum. Kanban não exige uma reunião diária, embora muitas equipes Kanban adotem uma. Não confunda a cerimônia com o framework.
• "Scrum funciona para hardware." Pode funcionar, mas o método do caminho crítico e os gráficos PERT frequentemente se encaixam melhor no desenvolvimento de hardware porque o hardware tem dependências sequenciais reais que as reinicializações do Sprint não mudam.

Scrumban: combinando os dois

Corey Ladas descreveu o Scrumban em um artigo de 2008 como uma forma de fazer a transição das equipes do Scrum para o Kanban. Na prática, ele evoluiu para um híbrido próprio: as equipes mantêm alguma cadência de planejamento parecida com Sprint (um "gatilho" que dispara quando o Backlog cai abaixo de um limite) enquanto usam os limites de WIP e métricas de fluxo do Kanban no próprio quadro.

É especialmente útil para equipes que são metade produto, metade suporte. O trabalho de produto se beneficia das metas do Sprint e dos ciclos de revisão. O trabalho de suporte não pode esperar por um limite de Sprint. Scrumban permite processar itens urgentes sem comprometer os compromissos do Sprint.

O risco: Scrumban também pode ser uma desculpa para evitar a disciplina de qualquer um dos frameworks. Se você está chamando de Scrumban, mas seus limites de WIP são sempre 10 e suas metas de Sprint são sempre "o que chegou esta semana," você não tem nem Scrum nem Kanban. Você tem um quadro branco etiquetado.

Perguntas frequentes

Kanban é uma metodologia ou uma ferramenta?

É uma metodologia. "Quadro Kanban" é um artefato do método Kanban, mas o próprio Kanban é um conjunto de práticas para gerenciar e melhorar o fluxo: visualizar o trabalho, limitar o WIP, gerenciar o fluxo, tornar as políticas de processo explícitas, implementar loops de feedback e melhorar colaborativamente. O quadro é a parte mais visível, mas os limites de WIP e as métricas de fluxo são o que fazem dele um método, e não apenas um hábito de post-its.

Uma equipe pode mudar do Scrum para o Kanban no meio de um projeto?

Sim, mas faça isso deliberadamente. A transição mais comum ocorre durante uma Retrospective da equipe, quando a equipe concorda que os ciclos de Sprint não estão adicionando valor. Os passos práticos: pare de planejar Sprints, torne os limites de WIP explícitos no seu quadro existente, comece a rastrear o tempo de ciclo em vez da Velocity, e execute uma revisão de fluxo em vez de uma Sprint Review. Não misture Sprint e Kanban simultaneamente durante a transição. Escolha uma data e mude.

Você precisa de um Scrum Master no Kanban?

Não. Kanban não tem papéis obrigatórios. Algumas organizações usam um "gerente de fluxo" ou "gerente de entrega de serviço" para conduzir reuniões de reabastecimento e proteger os limites de WIP, mas isso não é exigido pelo método Kanban. Equipes que adotam Kanban a partir do Scrum frequentemente mantêm seus Scrum Masters em um papel de coaching, e isso é aceitável. Apenas esteja claro que o papel agora é opcional, não obrigatório.

Com qual é mais fácil começar: Scrum ou Kanban?

Kanban é mais fácil de começar para a maioria das equipes porque não exige reorganização de papéis ou compromisso com um novo calendário de cerimônias. Você pode introduzir o Kanban simplesmente tornando seu fluxo de trabalho existente visível em um quadro e concordando com os limites de WIP. Scrum requer clareza de papéis (quem é o Product Owner?) e compromisso com as cerimônias (faremos o Sprint Planning a cada duas semanas) antes de funcionar como projetado. Dito isso, a cadência estruturada do Scrum é frequentemente uma vantagem para equipes que precisam de mecanismos de força para entregar regularmente. Se a sua equipe tem um histórico de "lançaremos quando estiver pronto" indefinidamente, a pressão do Sprint do Scrum pode ser exatamente o que você precisa.

---

A maioria das equipes acaba gastando tempo argumentando sobre qual framework é "melhor" quando deveria perguntar qual combina com o modo como o trabalho realmente chega. Scrum oferece um loop de feedback estruturado a cada uma a quatro semanas. Kanban oferece clareza de fluxo e previsibilidade no nível do item individual. Ambos superam trabalhar com uma planilha compartilhada e uma oração. Comece com o que se encaixa no padrão do seu trabalho, meça honestamente e itere a partir daí.

Para equipes que constroem planos de projeto estruturados junto com seu trabalho ágil, uma matriz RACI pode esclarecer a propriedade das decisões entre equipes de Sprint. E se seu histórico em metodologia waterfall estiver puxando você em direção ao planejamento sequencial, a estrutura de Sprint do Scrum geralmente é a ponte melhor do que ir direto para o fluxo contínuo do Kanban.