Diferença entre Kanban e Scrum: comparação e qual escolher

A diferença entre Kanban e Scrum está na forma de organizar o trabalho no tempo. O Scrum divide o trabalho em ciclos de duração fixa, as Sprints, com papéis e eventos definidos. O Kanban não tem ciclos obrigatórios: ele gerencia um fluxo contínuo e controla quanto trabalho está em andamento ao mesmo tempo. Os dois nasceram de ideias parecidas sobre entrega frequente e melhoria contínua, mas pedem rotinas bem diferentes da equipe.

Essa diferença decide muita coisa na prática: como as prioridades mudam, quando o cliente vê algo pronto, quantas reuniões a equipe tem e o que se mede. Escolher sem entender isso costuma gerar um "Scrum" sem Sprints ou um "Kanban" que é só um quadro com colunas.

A seguir você vê o que é cada um, a comparação lado a lado, os critérios para escolher e como usar os dois juntos. Para o panorama completo das abordagens ágeis, com valores, princípios e outros frameworks, consulte o guia de métodos ágeis e Scrum.

O que é Scrum

O Scrum é um framework leve para gerar valor por meio de soluções adaptativas para problemas complexos. Segundo o Guia do Scrum, na versão de 2020:

O Kanban.Global traz uma comparação detalhada entre Kanban e Scrum, com critérios para escolher.

• O trabalho acontece em Sprints, ciclos de duração fixa de um mês ou menos. Uma nova Sprint começa assim que a anterior termina.
• O Scrum Team tem três responsabilidades: o Product Owner, que maximiza o valor do produto e cuida do Product Backlog; o Scrum Master, que zela pela eficácia do time e pelo uso do Scrum; e os Developers, que constroem o incremento. Versões antigas do guia falavam em "Equipe de Desenvolvimento", termo que foi substituído.
• Há cinco eventos: a própria Sprint, a Sprint Planning, a Daily Scrum (de 15 minutos), a Sprint Review e a Sprint Retrospective.
• Há três artefatos, cada um com um compromisso: Product Backlog (Meta do Produto), Sprint Backlog (Meta da Sprint) e Incremento (Definição de Pronto).

A explicação completa de cada elemento está em o que é Scrum.

O que é Kanban

O Kanban Guide define o Kanban como uma estratégia para otimizar o fluxo de valor ao longo de um processo: se o fluxo melhora, o valor entregue melhora junto. O guia descreve três práticas:

• Definir e visualizar o fluxo de trabalho, normalmente num quadro com as etapas pelas quais um item passa.
• Gerenciar ativamente os itens no fluxo, controlando a quantidade de trabalho em andamento (o WIP, de work in progress), atuando em itens parados e evitando que o trabalho se acumule.
• Melhorar o fluxo, usando dados para ajustar o processo continuamente.

O guia pede quatro medidas de fluxo: trabalho em andamento, vazão (throughput), idade do item em andamento e tempo de ciclo. Não define papéis nem obriga iterações: as revisões podem acontecer de forma contínua, em intervalos regulares ou das duas formas. Um ponto central é o sistema puxado: um item novo só entra quando há capacidade, e não porque alguém empurrou mais uma tarefa. Os fundamentos estão em o que é Kanban.

Diferença entre Kanban e Scrum lado a lado

A tabela resume a comparação Scrum vs Kanban nos pontos que mais pesam na rotina da equipe.

Duas diferenças merecem atenção. A primeira é o compromisso: no Scrum, a equipe se compromete com uma meta para a Sprint; no Kanban, com manter o fluxo saudável e previsível. A segunda é a forma de adoção: o Scrum pede que a equipe passe a funcionar de outro jeito desde o início, enquanto o Kanban parte do processo existente, torna-o visível e muda o que os dados mostram que precisa mudar.

Quando usar Kanban ou Scrum

Quando o Kanban costuma funcionar melhor

• Demanda contínua e imprevisível, como suporte de TI, manutenção, atendimento de chamados, jurídico ou compras.
• Prioridades que mudam várias vezes por semana, em que esperar o fim de uma Sprint seria caro.
• Equipes que não podem parar para mudar papéis, mas precisam reduzir filas e atrasos já.
• Processos com etapas bem definidas, como produção de conteúdo ou aprovação de documentos.

Quando o Scrum costuma funcionar melhor

• Desenvolvimento de um produto novo, em que a equipe precisa construir em incrementos e aprender com o retorno do cliente a cada ciclo.
• Problemas complexos, com muitas incertezas, que se beneficiam de inspeção e adaptação em ritmo regular.
• Equipes que precisam de foco e de uma meta comum para não se dispersar entre pedidos.
• Clientes ou patrocinadores que querem ver o produto evoluir em momentos previsíveis, nas Sprint Reviews.

Exemplo ilustrativo

Numa secretaria municipal, a equipe que desenvolve o novo portal de serviços ao cidadão trabalha bem com Scrum: há um produto a construir, muitas dúvidas sobre o que o cidadão precisa e valor em mostrar uma versão nova a cada duas semanas. Já a equipe que atende chamados dos sistemas existentes trabalha melhor com Kanban: os pedidos chegam todos os dias, com urgências diferentes, e o que importa é não deixar a fila crescer. As duas equipes podem conviver na mesma área, cada uma com a abordagem que combina com o seu tipo de trabalho. O exemplo é ilustrativo.

Scrum e Kanban juntos

Scrum e Kanban não são excludentes. Muitas equipes Scrum usam práticas Kanban para melhorar o fluxo dentro da Sprint: visualizam as etapas do trabalho num quadro, limitam o trabalho em andamento para terminar antes de começar e acompanham a idade dos itens para identificar o que está travado. O Scrum continua com seus eventos e responsabilidades; o Kanban acrescenta disciplina de fluxo.

O que não funciona é misturar sem critério. Uma equipe que abandona a Sprint Review e a Retrospective, mas continua chamando o processo de Scrum, perde a inspeção e a adaptação que dão sentido ao framework. E uma equipe que coloca um quadro na parede sem limitar o trabalho em andamento não está usando Kanban: está apenas listando tarefas. As formas de combinar os dois, com os cuidados de cada uma, estão em como combinar Scrum e Kanban.

Erros comuns na escolha

• Escolher pelo que parece mais fácil. Kanban parece mais simples por não ter papéis, mas exige disciplina para respeitar o limite de trabalho em andamento.
• Escolher pela ferramenta. Ter um quadro no software não define a abordagem; a forma de trabalhar define.
• Copiar outra equipe. O que funciona para a equipe de produto pode não servir para a equipe de suporte da mesma empresa.
• Nunca revisar a escolha. Uma equipe pode começar com Kanban e passar a usar Scrum quando assumir um produto novo, ou o contrário.

Próximo passo

Olhe para o trabalho que chegou à sua equipe nas últimas quatro semanas. Se a maior parte foi demanda contínua e imprevisível, comece pelo Kanban: desenhe o fluxo, combine um limite de trabalho em andamento e meça o tempo de ciclo. Se a maior parte foi construção de algo novo, com muitas dúvidas, experimente Scrum por algumas Sprints. Para aprender a montar o sistema, definir limites e ler as métricas do fluxo com orientação, o curso de Kanban da Projeto Diário percorre o método da primeira coluna do quadro à melhoria contínua.