Duas perguntas diferentes
Kanban e Scrum são frequentemente servidos como dois pratos do mesmo menu. Na prática, começam com perguntas diferentes. Kanban pergunta: onde é que o trabalho fica preso? Scrum pergunta: o que podemos entregar até ao final do ciclo? O resto da comparação segue-se daí.
Kanban: observar o fluxo
O Guia Kanban (edição de maio de 2025) define Kanban como uma estratégia para otimizar o fluxo de valor através de um processo. Baseia-se em três práticas: definir e visualizar o fluxo de trabalho, gerir ativamente os itens que nele passam e melhorar o fluxo. Sem iterações impostas, sem funções prescritas. Um requisito é verdadeiramente firme: controlar o número de itens em progresso, desde o momento em que são iniciados até ao momento em que estão concluídos.
Porque é que esse limite é tão importante? Porque atua diretamente sobre o tempo que uma tarefa demora a atravessar o tabuleiro. A lei de Little diz que, num sistema estável, o número médio de itens em progresso é igual ao débito médio multiplicado pelo tempo médio que um item passa no sistema (Little, 2011).
Um exemplo com números inventados para a ocasião. Uma equipa de suporte termina cerca de 5 tickets por dia e tem sempre 20 abertos: cada ticket demora em média 4 dias a sair (20 ÷ 5). Se a equipa limitar os tickets em curso a 8 sem que o seu throughput diminua, a média desce para 1,6 dias (8 ÷ 5). Nada foi acelerado; a equipa simplesmente parou de começar tudo de uma vez.
Scrum: manter o ritmo
O Guia Scrum 2020, de Ken Schwaber e Jeff Sutherland, descreve Scrum como uma estrutura leve que ajuda pessoas, equipas e organizações a gerar valor através de soluções adaptativas para problemas complexos. É preciso apenas em alguns pontos: Sprints de um mês ou menos, uma equipa de dez pessoas ou menos, três responsabilidades (Desenvolvedores, Product Owner, Scrum Master), cinco eventos incluindo a própria Sprint e três artefactos (Produto Backlog, Sprint Backlog, Incremento). Cada Sprint persegue um único objetivo, o Sprint Objetivo. Os detalhes encontram-se no nosso artigo sobre o método Scrum.
O que muda na prática
| Criterion | Kanban | Scrum |
|---|---|---|
| Pergunta inicial | Onde é que o trabalho para? | O que entregamos no final do Sprint? |
| O que fica limitado | O número de itens em progresso | A duração do Sprint (no máximo um mês) |
| Funções obrigatórias | Nenhuma | Product Owner, Scrum Master, Desenvolvedores |
| Mudar de ideias a meio do caminho | Possível a qualquer momento, dentro do limite de WIP | A backlog pode ser reordenada; apenas a Product Owner pode cancelar uma Sprint |
| Medidas comuns | Tempo de ciclo, débito | Sprint Objetivo atingido ou não (a velocidade é uma prática comum, mas o Guia não a menciona) |
Como escolher sem se perder
- O trabalho chega continuamente, em pequenas partes, sem prazo partilhado (suporte, conteúdo, recrutamento): Kanban encaixa melhor, pois não existe um entregue coletivo para fixar num calendário.
- A equipa está a construir um produto ou uma campanha e quer um ponto de controlo regular com as partes interessadas: Scrum proporciona esse ritmo, desde que os eventos sejam realmente realizados.
- Kanban sem limite de WIP torna-se uma lista de tarefas mais apresentável. Scrum sem uma retrospetiva que mude algo torna-se uma série de reuniões.
Muitas equipas misturam os dois. Para uma visão geral do que a literatura registou sobre Kanban em software, veja a revisão sistemática de Ahmad, Markkula e Oivo (2013).
Fontes
- Coleman, J., Vacanti, D., et al. (2025). The Kanban Guide (maio de 2025). kanbanguides.org
- Schwaber, K., & Sutherland, J. (2020). O Guia Scrum 2020. scrumguides.org
- Little, J. D. C. (2011). Fórum OR: A Lei de Little vista no seu 50.º aniversário. Investigação Operacional, 59(3), 536-549. doi:10.1287/OPRE.1110.0940
- Ahmad, M. O., Markkula, J., & Oivo, M. (2013).Kanban em desenvolvimento de software: Revisão sistemática da literatura. 39.ª Conferência EUROMICRO sobre Engenharia de Software e Aplicações Avançadas, 9-16. doi:10.1109/SEAA.2013.28