7 min leitura • Guide 530 of 877
Guia de Decisão Kanban vs Scrum
Escolher entre Kanban e Scrum depende dos padrões de trabalho do seu time, cadência de entrega e cultura organizacional. O GitScrum suporta ambas as metodologias completamente, permitindo que times comecem com uma abordagem e evoluam seu processo conforme aprendem o que funciona melhor para seu contexto específico.
Visão Geral Comparativa
| Aspecto | Scrum | Kanban |
|---|---|---|
| Cadência | Sprints fixas (1-4 semanas) | Fluxo contínuo |
| Planejamento | Eventos de sprint planning | Priorização just-in-time |
| Papéis | Definidos (PO, SM, Time Dev) | Flexíveis |
| Mudanças | Sprint backlog congelado | Mudar a qualquer hora |
| Métricas | Velocity, burndown | Lead time, throughput |
| Melhor para | Desenvolvimento de produto | Operações, suporte |
Framework de Decisão
GUIA DE SELEÇÃO DE METODOLOGIA
PERGUNTA 1: PREVISIBILIDADE DO TRABALHO
┌─────────────────────────────────────────────────┐
│ O trabalho que chega é previsível? │
│ │
│ Principalmente features planejadas → SCRUM │
│ Mix de planejado e interrupções → SCRUMBAN │
│ Principalmente reativo/suporte → KANBAN │
└─────────────────────────────────────────────────┘
PERGUNTA 2: CADÊNCIA DE RELEASE
┌─────────────────────────────────────────────────┐
│ Como vocês fazem releases? │
│ │
│ Releases regulares cada 2-4 semanas → SCRUM │
│ Deploy contínuo diário → KANBAN │
│ Mix: features + hotfixes → SCRUMBAN │
└─────────────────────────────────────────────────┘
PERGUNTA 3: ESTABILIDADE DE PRIORIDADES
┌─────────────────────────────────────────────────┐
│ Com que frequência prioridades mudam? │
│ │
│ Estáveis por 2-4 semanas → SCRUM │
│ Mudam em dias → KANBAN │
│ Mudanças ocasionais mid-sprint → SCRUMBAN │
└─────────────────────────────────────────────────┘
PERGUNTA 4: MATURIDADE DO TIME
┌─────────────────────────────────────────────────┐
│ Experiência ágil do time? │
│ │
│ Novo em ágil, precisa estrutura → SCRUM │
│ Experiente, auto-organizável → KANBAN │
│ Experiente, quer flexibilidade → SCRUMBAN │
└─────────────────────────────────────────────────┘
PERGUNTA 5: EXPECTATIVAS DOS STAKEHOLDERS
┌─────────────────────────────────────────────────┐
│ O que stakeholders esperam? │
│ │
│ Demos regulares, datas previsíveis → SCRUM │
│ "Só entreguem" flexibilidade → KANBAN │
│ Estrutura e flexibilidade → SCRUMBAN │
└─────────────────────────────────────────────────┘
Recomendações por Cenário
RECOMENDAÇÕES DE CENÁRIO
CENÁRIO 1: DESENVOLVIMENTO DE PRODUTO NOVO
┌─────────────────────────────────────────────────┐
│ Contexto: │
│ • Construindo novo produto SaaS │
│ • Roadmap de features claro │
│ • Reviews regulares com stakeholders necessários│
│ • Time de 5-8 desenvolvedores │
│ │
│ Recomendação: SCRUM │
│ • Sprints de 2 semanas │
│ • Demos de sprint para stakeholders │
│ • Tracking de velocity previsível │
│ • Definition of done clara │
└─────────────────────────────────────────────────┘
CENÁRIO 2: TIME DE SUPORTE/OPERAÇÕES
┌─────────────────────────────────────────────────┐
│ Contexto: │
│ • Atendendo tickets de suporte │
│ • Resposta a incidentes │
│ • Prioridades mudam diariamente │
│ • SLAs direcionam prioridade do trabalho │
│ │
│ Recomendação: KANBAN │
│ • Lane de expedite para issues críticos │
│ • Limites de WIP para gerenciar fluxo │
│ • Classes de serviço para SLAs diferentes │
│ • Deploy contínuo │
└─────────────────────────────────────────────────┘
CENÁRIO 3: TIME MISTO (FEATURES + SUPORTE)
┌─────────────────────────────────────────────────┐
│ Contexto: │
│ • Construindo features E corrigindo bugs │
│ • Trabalho parte planejado, parte reativo │
│ • Precisa previsibilidade mas também flexibilidade│
│ • Escalações de cliente acontecem │
│ │
│ Recomendação: SCRUMBAN │
│ • Sprint planning com capacidade buffer │
│ • Limites de WIP dentro da sprint │
│ • Lane de bugs com fluxo contínuo │
│ • Resposta flexível a urgências │
└─────────────────────────────────────────────────┘
Comparação Detalhada
Estrutura e Cerimônias
ESTRUTURA COMPARATIVA
═════════════════════
SCRUM:
─────────────────────────────────────
Cerimônias obrigatórias:
├── Sprint Planning (2-4h)
├── Daily Standup (15min)
├── Sprint Review (1-2h)
└── Retrospectiva (1-1.5h)
Papéis definidos:
├── Product Owner
├── Scrum Master
└── Time de Desenvolvimento
Artefatos:
├── Product Backlog
├── Sprint Backlog
└── Incremento
KANBAN:
─────────────────────────────────────
Cerimônias opcionais:
├── Replenishment meeting (conforme necessário)
├── Daily standup (opcional)
├── Service delivery review (periódico)
└── Retrospectiva (conforme necessário)
Papéis:
├── Não prescritos
├── Emergem conforme necessidade
└── Time auto-organizável
Artefatos:
├── Board Kanban
├── Políticas de coluna
└── Métricas de fluxo
Métricas e Visibilidade
MÉTRICAS COMPARATIVAS
═════════════════════
SCRUM:
─────────────────────────────────────
┌────────────────────────────────────┐
│ BURNDOWN CHART │
│ │
│ Pontos│ ╲ │
│ 20 │ ╲ │
│ 15 │ ╲_ │
│ 10 │ ╲_ │
│ 5 │ ╲_ │
│ 0 │─────────╲──────────────── │
│ └─────────────────────────── │
│ D1 D3 D5 D7 D9 D10 │
└────────────────────────────────────┘
Velocity: Pontos por sprint
Previsibilidade: "Em X sprints entregamos"
KANBAN:
─────────────────────────────────────
┌────────────────────────────────────┐
│ LEAD TIME DISTRIBUTION │
│ │
│ Freq │ ████ │
│ │ ████████ │
│ │ ████████████ │
│ │ ████████████████ │
│ │ ████████████████████ │
│ └─────────────────────────── │
│ 2d 4d 6d 8d 10d 12d │
│ Lead Time │
└────────────────────────────────────┘
Throughput: Itens por semana
Previsibilidade: "85% dos itens levam até X dias"
Transição Entre Metodologias
De Scrum para Kanban
TRANSIÇÃO SCRUM → KANBAN
════════════════════════
QUANDO CONSIDERAR:
├── Sprints frequentemente interrompidas
├── Time experiente e auto-organizável
├── Trabalho muito variável
├── Cerimônias parecem overhead
PASSOS:
─────────────────────────────────────
1. MANTER:
• Daily standups
• Retrospectivas periódicas
• Visualização do trabalho
2. MODIFICAR:
• Sprints → Fluxo contínuo
• Sprint planning → Replenishment contínuo
• Velocity → Lead time/throughput
3. ADICIONAR:
• Limites de WIP explícitos
• Políticas de coluna claras
• Classes de serviço
4. REMOVER GRADUALMENTE:
• Sprint boundaries
• Commitment fixo
• Burndown charts
De Kanban para Scrum
TRANSIÇÃO KANBAN → SCRUM
════════════════════════
QUANDO CONSIDERAR:
├── Time precisa mais estrutura
├── Stakeholders querem previsibilidade
├── Releases regulares necessários
├── Falta de ritmo causa problemas
PASSOS:
─────────────────────────────────────
1. MANTER:
• Board visual
• WIP awareness
• Métricas de fluxo (como complemento)
2. ADICIONAR:
• Sprints com duração fixa
• Sprint planning
• Sprint reviews
• Retrospectivas regulares
• Papéis definidos
3. MODIFICAR:
• Fluxo contínuo → Iterações
• Priorização on-demand → Planning
• Lead time → Velocity
4. AJUSTAR:
• Definition of Done clara
• Sprint backlog protegido
• Commitment de sprint
Melhores Práticas
Escolhendo com Sucesso
CHECKLIST DE DECISÃO
════════════════════
ANTES DE ESCOLHER:
☐ Entender padrões de trabalho do time
☐ Avaliar expectativas dos stakeholders
☐ Considerar maturidade ágil
☐ Analisar tipo de trabalho predominante
AO IMPLEMENTAR:
☐ Começar simples
☐ Adaptar conforme aprende
☐ Medir impacto
☐ Colher feedback do time
EVOLUÇÃO:
☐ Revisar escolha trimestralmente
☐ Ajustar baseado em dados
☐ Não ter medo de mudar
☐ Combinar elementos se fizer sentido
A escolha entre Kanban e Scrum não precisa ser definitiva—o importante é que a metodologia sirva o time e o contexto, não o contrário.