7 min leitura • Guide 383 of 877
Kanban vs Scrum Workflow
Kanban e Scrum são abordagens diferentes para gerenciar trabalho. Nenhuma é universalmente melhor—a escolha certa depende do contexto do seu time, tipo de trabalho e necessidades organizacionais. Este guia ajuda você a escolher e implementar o workflow correto.
Comparação
| Aspecto | Scrum | Kanban |
|---|---|---|
| Período | Sprints (1-4 semanas) | Contínuo |
| Papéis | Scrum Master, PO, Time | Sem papéis obrigatórios |
| Reuniões | Cerimônias definidas | Conforme necessário |
| Mudanças | Após sprint | A qualquer momento |
| Métricas | Velocity | Lead time, throughput |
Visão Geral do Scrum
Trabalho Baseado em Sprint
FRAMEWORK SCRUM
═══════════════
PAPÉIS:
─────────────────────────────────────
├── Product Owner: Prioriza backlog
├── Scrum Master: Facilita processo
├── Time de Desenvolvimento: Faz o trabalho
└── Responsabilidades claras
CERIMÔNIAS:
─────────────────────────────────────
├── Sprint Planning: O que fazer
├── Daily Standup: Sync e bloqueios
├── Sprint Review: Demo do trabalho feito
├── Retrospectiva: Como melhorar
└── Ritmo regular
ARTEFATOS:
─────────────────────────────────────
├── Product Backlog: Todo trabalho
├── Sprint Backlog: Trabalho desta sprint
├── Incremento: Entrega resultante
└── Trabalho visível
CICLO DA SPRINT:
─────────────────────────────────────
Planning → Desenvolvimento → Review → Retro
└──────────────────────────────┘
2 semanas (exemplo)
QUANDO SCRUM FUNCIONA:
─────────────────────────────────────
├── Desenvolvimento de produto
├── Times podem se comprometer com sprints
├── Querem entrega previsível
├── Precisam feedback regular de stakeholders
├── Se beneficiam de ritmo de planejamento
└── Trabalho de features
Visão Geral do Kanban
Fluxo Contínuo
FRAMEWORK KANBAN
════════════════
PRINCÍPIOS:
─────────────────────────────────────
├── Visualizar trabalho
├── Limitar trabalho em progresso
├── Gerenciar fluxo
├── Tornar políticas explícitas
├── Melhoria contínua
└── Baseado em fluxo
BOARD KANBAN:
─────────────────────────────────────
│Backlog│A Fazer│Em Prog│ Review │Concluído│
│ │ (3) │ (3) │ (2) │ │
├───────┼───────┼───────┼────────┼─────────┤
│ Item │ Item │ Item │ Item │ Feito │
│ Item │ Item │ Item │ Item │ Feito │
│ Item │ Item │ │ │ Feito │
│ Item │ │ │ │ │
Números = limites de WIP
LIMITES DE WIP:
─────────────────────────────────────
Por que limites importam:
├── Previne sobrecarga
├── Expõe gargalos
├── Terminar antes de começar novo
├── Melhora fluxo
├── Reduz troca de contexto
└── Essencial para Kanban
QUANDO KANBAN FUNCIONA:
─────────────────────────────────────
├── Times de suporte
├── Correção de bugs
├── Trabalho de operações
├── Entrada imprevisível
├── Não pode se comprometer com sprints
├── Trabalho de manutenção
└── Fluxo contínuo
Escolhendo Entre Eles
Framework de Decisão
GUIA DE ESCOLHA
═══════════════
ESCOLHA SCRUM SE:
─────────────────────────────────────
☑ Construindo produto com roadmap claro
☑ Time pode proteger tempo da sprint
☑ Stakeholders querem demos regulares
☑ Trabalho é principalmente features
☑ Time se beneficia de ritmo estruturado
☑ Querem tracking de velocity
☑ Precisam de estimativas previsíveis
ESCOLHA KANBAN SE:
─────────────────────────────────────
☑ Trabalho chega imprevisível (suporte)
☑ Prioridades mudam frequentemente
☑ Não pode se comprometer com sprints
☑ Trabalho é principalmente reativo
☑ Time é experiente e auto-organizável
☑ Quer deploy contínuo
☑ Precisa resposta rápida a urgências
ESCOLHA SCRUMBAN SE:
─────────────────────────────────────
☑ Trabalho misto (features + suporte)
☑ Transitioning entre metodologias
☑ Quer estrutura com flexibilidade
☑ Sprint planning mas WIP limits
☑ Nem totalmente Scrum nem Kanban
Implementando Scrum
Configuração de Sprint
SETUP DE SPRINT NO GITSCRUM
═══════════════════════════
CRIAR SPRINT:
─────────────────────────────────────
Sprint: Sprint 15
Início: 13 Janeiro
Fim: 26 Janeiro
Meta: Completar fluxo de checkout
PLANEJAMENTO:
─────────────────────────────────────
1. Product Owner apresenta prioridades
2. Time seleciona itens para sprint
3. Time quebra em tarefas
4. Comprometimento com meta
5. Sprint backlog definido
BOARD DA SPRINT:
─────────────────────────────────────
┌──────────────────────────────────────────┐
│ Sprint 15: Fluxo de Checkout │
├────────┬────────┬────────┬────────┬──────┤
│A Fazer │Em Prog │Review │Teste │Pronto│
├────────┼────────┼────────┼────────┼──────┤
│ ○○○○ │ ○○ │ ○ │ ○ │ ○○○ │
│ ○○ │ ○ │ │ │ ○○ │
└────────┴────────┴────────┴────────┴──────┘
CERIMÔNIAS CONFIGURADAS:
─────────────────────────────────────
├── Planning: Seg 13 Jan, 9h (2h)
├── Daily: Seg-Sex, 9h30 (15min)
├── Review: Sex 26 Jan, 14h (1h)
└── Retro: Sex 26 Jan, 15h30 (1h)
Implementando Kanban
Configuração do Board
SETUP KANBAN NO GITSCRUM
════════════════════════
COLUNAS E LIMITES:
─────────────────────────────────────
┌───────────────────────────────────────────┐
│ Board: Suporte ao Cliente │
├──────┬──────┬──────┬──────┬──────┬───────┤
│Inbox │Triado│Em Prog│Review│ QA │Concluído│
│ ∞ │ 5 │ 3 │ 2 │ 2 │ ∞ │
├──────┼──────┼──────┼──────┼──────┼───────┤
│ ○○○ │ ○○ │ ○○ │ ○ │ ○○ │ ○○○○ │
│ ○○ │ ○○ │ ○ │ ○ │ │ ○○○ │
│ ○ │ ○ │ │ │ │ │
└──────┴──────┴──────┴──────┴──────┴───────┘
CLASSES DE SERVIÇO:
─────────────────────────────────────
🔴 Expedite: SLA 4h (bypass WIP)
🟠 Urgent: SLA 24h
🟡 Standard: SLA 72h
🟢 Low: SLA 1 semana
POLÍTICAS DE COLUNA:
─────────────────────────────────────
Inbox → Triado:
• Reproduzido ou info suficiente
• Prioridade definida
• Estimativa rough (P/M/G)
Triado → Em Progresso:
• Puxar quando capacidade
• Respeitar WIP limit
• Começar pelo mais antigo da prioridade
Em Progresso → Review:
• Solução implementada
• Testes inclusos
• PR aberto
Scrumban: Híbrido
Combinando Abordagens
SETUP SCRUMBAN
══════════════
ESTRUTURA:
─────────────────────────────────────
Do Scrum:
├── Sprints de 2 semanas
├── Sprint planning
├── Daily standups
├── Retrospectivas
└── Sprint reviews
Do Kanban:
├── WIP limits por coluna
├── Pull quando capacidade
├── Classes de serviço
├── Métricas de fluxo
└── Sem commitment fixo
BOARD SCRUMBAN:
─────────────────────────────────────
┌────────────────────────────────────────────┐
│ Sprint 15 + Kanban Flow │
├──────┬──────┬──────┬──────┬──────┬────────┤
│Sprint│Ready │ Dev │Review│ QA │Concluído│
│Buffer│ (4) │ (4) │ (2) │ (2) │ │
├──────┼──────┼──────┼──────┼──────┼────────┤
│ │ │ │ │ │ │
│Features planejadas na sprint │
│ │ │ │ │ │ │
├──────┴──────┴──────┴──────┴──────┴────────┤
│Bugs│ Triado│Em Prog│Review│ Done │ │
│ ∞ │ (3) │ (2) │ (1) │ │ │
├────┼───────┼───────┼──────┼──────┼────────┤
│ │ │ │ │ │ │
│Bugs fluem continuamente (Kanban) │
└────────────────────────────────────────────┘
Métricas por Metodologia
Comparativo
MÉTRICAS SCRUM:
─────────────────────────────────────
Velocity: Pontos/sprint
Sprint 14: 34 pontos
Sprint 15: 38 pontos
Média: 36 pontos
Burndown: Progresso na sprint
Ideal vs Real
Commitment vs Delivered:
Comprometido: 40 pontos
Entregue: 38 pontos (95%)
MÉTRICAS KANBAN:
─────────────────────────────────────
Lead Time: Pedido → Entrega
P50: 4.2 dias
P85: 7.1 dias
P95: 12.3 dias
Cycle Time: Início → Entrega
P50: 2.1 dias
P85: 3.8 dias
Throughput: Itens/semana
Última semana: 12 itens
Média 4 semanas: 11.5 itens
Eficiência de Fluxo:
Tempo ativo / Tempo total = 35%
Melhores Práticas
Implementação
CHECKLIST DE IMPLEMENTAÇÃO
══════════════════════════
SCRUM:
☐ Definir duração da sprint
☐ Agendar cerimônias
☐ Configurar board de sprint
☐ Definir Definition of Done
☐ Treinar time nos papéis
☐ Criar product backlog
KANBAN:
☐ Mapear workflow atual
☐ Definir colunas do board
☐ Estabelecer WIP limits
☐ Documentar políticas
☐ Configurar métricas de fluxo
☐ Treinar time em pull
SCRUMBAN:
☐ Configurar sprint + WIP
☐ Separar tipos de trabalho
☐ Definir o que é planejado vs fluxo
☐ Métricas de ambos
☐ Clarificar quando puxar vs quando planejar
A escolha do workflow deve servir ao time e ao contexto, não o contrário. Comece com uma abordagem e evolua baseado no que funciona.