Scrum vs Kanban: as diferenças e qual serve a uma equipa pequena
Por Andrei Finogeev, fundador do Weft ·
O Scrum planeia o trabalho em sprints fixos de um mês ou menos, com três responsabilidades (Product Owner, Scrum Master, Developers) e quatro eventos dentro de cada sprint. O Kanban não tem sprints nem papéis prescritos: o trabalho flui continuamente pelo quadro, e a equipa limita explicitamente quanto está em curso. Escolha o Scrum quando uma equipa de várias pessoas precisa de um ritmo de entrega fixo e de um objetivo estável por ciclo; escolha o Kanban quando o trabalho chega de forma imprevisível e as prioridades mudam todos os dias. O Scrumban fica entre os dois: o fluxo do Kanban, com sprints apenas onde ajudam.
Scrum vs Kanban vs Scrumban: resumo
Scrum tal como definido no Scrum Guide de 2020; Kanban tal como definido no Kanban Guide (v2025.5). O Scrumban não tem guia oficial; a coluna descreve como costuma ser aplicado.
| Scrum | Kanban | Scrumban | |
|---|---|---|---|
| Cadência | Sprints fixos de um mês ou menos, seguidos | Fluxo contínuo, sem iterações | Fluxo contínuo; sprints opcionais, normalmente de uma ou duas semanas |
| Papéis | Product Owner, Scrum Master, Developers | Nenhum prescrito | Nenhum prescrito; muitas vezes uma pessoa é dona das prioridades |
| Reuniões | Sprint Planning, Daily Scrum (15 min), Sprint Review, Sprint Retrospective | Nenhuma prescrita | Só as que a equipa considera úteis, normalmente um planeamento e uma revisão |
| O que limita o trabalho | O que a equipa assume para o sprint | Um limite explícito ao trabalho em curso | Um limite ao trabalho em curso, mais o objetivo do sprint, se existir |
| Mudar o âmbito a meio do ciclo | O Objetivo do Sprint mantém-se fixo; o Sprint Backlog pode ser refinado | A qualquer momento: o item seguinte é puxado quando há espaço | A qualquer momento; o objetivo do sprint é um alvo, não um cadeado |
| Principais métricas | Progresso rumo ao Objetivo do Sprint e ao Objetivo do Produto | Trabalho em curso, throughput, idade dos itens de trabalho, cycle time | Normalmente as métricas de fluxo do Kanban |
| Quadro | Opcional; reiniciado a cada sprint | O núcleo do método; permanente | Permanente; um sprint é uma fatia dele |
| Funciona melhor para | Equipas de produto de até cerca de dez pessoas a trabalhar para um objetivo | Suporte, operações e quem recebe trabalho não planeado | Equipas pequenas e fundadores a solo que querem fluxo e um objetivo de curto prazo |
O que é o Scrum
O Scrum foi apresentado pela primeira vez por Ken Schwaber e Jeff Sutherland na conferência OOPSLA em 1995; as regras atuais são as do Scrum Guide de 2020. Uma Scrum Team tem normalmente dez pessoas ou menos e trabalha em sprints: eventos de duração fixa de um mês ou menos que começam logo a seguir ao fim do anterior.
Cada sprint tem quatro eventos. A Sprint Planning (no máximo oito horas para um sprint de um mês) define o Objetivo do Sprint e escolhe o trabalho. A Daily Scrum é um ponto de situação de 15 minutos para os Developers. A Sprint Review (no máximo quatro horas) mostra o resultado às partes interessadas, e a Sprint Retrospective (no máximo três horas) analisa a forma como a equipa trabalhou.
O Scrum tem três artefactos, cada um com um compromisso: o Product Backlog (o Objetivo do Produto), o Sprint Backlog (o Objetivo do Sprint) e o Incremento (a Definição de Concluído).
O que é o Kanban
O Kanban Guide define o Kanban como "uma estratégia para otimizar o fluxo de valor através de um processo". Tem origem no sistema de cartões que a Toyota usava para sinalizar quando produzir mais e foi adaptado ao trabalho do conhecimento na década de 2000.
Tem três práticas: definir e visualizar o fluxo de trabalho, gerir ativamente os itens que nele estão e melhorá-lo. A única regra rígida é que as pessoas no sistema controlam explicitamente quantos itens estão em curso entre o início e o fim: o limite de trabalho em curso (WIP).
O Kanban não prescreve papéis, sprints nem reuniões. Acompanha quatro métricas de fluxo: trabalho em curso, throughput, idade dos itens de trabalho e cycle time.
Prós e contras
Scrum
- Um ritmo fixo: todos sabem quando sai o próximo resultado
- Um objetivo claro por sprint impede a equipa de se dispersar
- Momentos integrados para inspecionar o produto e o processo
- Quatro eventos por sprint são um verdadeiro custo de tempo para uma equipa de duas ou três pessoas
- O trabalho urgente ou espera pelo sprint seguinte ou estraga o plano
- Exige alguém em cada responsabilidade, o que um fundador sozinho não consegue dividir
Kanban
- Começa no quadro que já tem; basta acrescentar um limite de WIP
- Pode ser puxado trabalho novo a qualquer momento
- As métricas de fluxo mostram onde o trabalho fica preso
- Não tem prazo nem objetivo integrados, por isso o trabalho longo pode arrastar-se
- Sem limite de WIP, é apenas uma lista de tarefas com colunas
- O planeamento a prazo fica inteiramente a cargo da equipa
Qual escolher
- Uma equipa de produto de cinco a dez pessoas com um roadmap estável
- Scrum. Os eventos compensam quando várias pessoas têm de chegar a acordo sobre um objetivo de duas em duas semanas, mais ou menos.
- Suporte, operações ou uma equipa que vive de pedidos que vão chegando
- Kanban. O trabalho chega quando chega; um limite de WIP e uma coluna Done clara importam mais do que um plano de sprint.
- Um fundador a solo ou uma equipa de duas a cinco pessoas
- Scrumban. Mantenha um quadro contínuo com limite de WIP e use um sprint de uma ou duas semanas como objetivo de curto prazo, sem o conjunto completo de eventos do Scrum.
Scrumban: o meio-termo
O Scrumban foi descrito por Corey Ladas como uma forma de as equipas Scrum evoluírem para um fluxo puxado. Na prática, é um quadro Kanban com limites de WIP que nunca é reiniciado, mais sprints como time-boxes opcionais que agrupam parte do trabalho. O nosso guia completo explica as regras e como montar o quadro: O que é o Scrumban?
Quando agentes de IA fazem parte do trabalho
Se o ChatGPT, o Claude, o Cursor ou o Codex pegam em tarefas por si, os eventos do Scrum não têm quem neles participe: um agente não vai à daily. O que continua a importar é o que o Kanban oferece: um quadro que mostra o que está em curso, um limite de WIP para que não se comecem dez tarefas ao mesmo tempo e uma regra clara para quando um cartão está concluído.
O estrangulamento também muda de sítio. Os agentes terminam o trabalho depressa, e o passo lento passa a ser a sua revisão do que fizeram. Um limite para quanto trabalho concluído pode ficar à sua espera é um limite de WIP na coluna humana.
O Weft é um quadro Scrumban feito para isto: colunas, sprints opcionais, um limite para quanto trabalho concluído pode aguardar a sua revisão e uma IA que assume uma tarefa antes de começar, reporta o progresso e para para lhe perguntar quando só o utilizador pode decidir.
Perguntas
O Scrum e o Kanban são a mesma coisa?
Não. Ambos são abordagens ágeis e ambos usam muitas vezes um quadro, mas o Scrum planeia o trabalho em sprints fixos com papéis e eventos definidos, enquanto o Kanban tem fluxo contínuo, nenhum papel prescrito e um limite explícito ao trabalho em curso.
Fazem-se sprints no Kanban?
Não no Kanban propriamente dito: o Kanban Guide não prescreve iterações. As equipas que acrescentam sprints a um quadro Kanban estão normalmente a fazer Scrumban.
Como funciona um sprint de Scrum?
Um sprint é um período fixo de um mês ou menos. Começa com a Sprint Planning, que define o Objetivo do Sprint; os Developers reúnem-se numa Daily Scrum de 15 minutos; termina com uma Sprint Review do resultado e uma Sprint Retrospective sobre o processo, e o sprint seguinte começa de imediato.
Quem inventou o Scrumban?
O termo é atribuído a Corey Ladas, que descreveu o Scrumban em ensaios e num livro de 2009 como uma forma de as equipas Scrum evoluírem para o fluxo puxado ao estilo Kanban.
O Scrum é o mesmo que Agile?
Não. Agile é o conjunto de valores e princípios do Manifesto Ágil de 2001; o Scrum e o Kanban são duas formas concretas de trabalhar que os seguem.
Um programador a solo pode usar Scrum?
Não tal como está escrito: o Scrum pressupõe uma equipa com três responsabilidades separadas. Um programador a solo costuma ficar com as partes que ajudam, um backlog e um objetivo de sprint curto, e gere o quadro como Kanban — o que é Scrumban.
Fontes
Lido a 11 de novembro de 2026.