7 min leitura • Guide 121 of 877
Criando Backlogs de Sprint Efetivos
Um backlog de sprint muito ambicioso leva a falha e desmoralização. Um que é muito leve desperdiça capacidade. Criar backlogs de sprint efetivos significa selecionar a quantidade certa do trabalho certo, adequadamente preparado e compreendido pela equipe.
Problemas de Backlog de Sprint
| Problema | Impacto | Solução |
|---|---|---|
| Supercomprometimento | Sprint perdido, desmoralização | Use dados velocidade |
| Trabalho pouco claro | Confusão meio-sprint | Refinamento adequado |
| Itens muito grandes | Nunca terminam | Quebre tarefas |
| Dependências ocultas | Trabalho bloqueado | Mapeamento dependências |
| Sem prioridades | Trabalho errado primeiro | Ordenação clara |
Prontidão do Backlog
Definição de Pronto
DEFINIÇÃO DE PRONTO (DoR)
═════════════════════════
Uma tarefa está PRONTA para sprint quando:
CLAREZA:
- [ ] Descrição é clara e completa
- [ ] Critérios aceitação definidos
- [ ] "Por que" é compreendido (contexto/valor)
- [ ] Questões foram respondidas
TAMANHO:
- [ ] Estimada pela equipe
- [ ] Pode completar dentro sprint
- [ ] Idealmente 1-3 dias trabalho
- [ ] Itens maiores são quebrados
DEPENDÊNCIAS:
- [ ] Sem dependências bloqueadoras
- [ ] Dependências externas identificadas
- [ ] Pré-requisitos completos ou agendados
RECURSOS:
- [ ] Designs/mockups disponíveis (se necessário)
- [ ] Especificações API disponíveis (se necessário)
- [ ] Dados teste/ambientes prontos
- [ ] Habilidades existem na equipe
Pronto vs Não Pronto
PRONTO VS NÃO PRONTO
════════════════════
✓ PRONTO:
"Implementar fluxo reset senha"
- Endpoint API documentado
- Template email aprovado
- Critérios aceitação: 5 itens específicos
- Estimativa: 5 pontos
- Sem bloqueadores
✗ NÃO PRONTO:
"Construir autenticação usuário"
- Muito vago - qual método auth?
- Sem especificações API
- Sem critérios aceitação
- Sem estimativa
- Depende de trabalho inacabado
Processo Planejamento Sprint
Cálculo Capacidade
CÁLCULO CAPACIDADE
══════════════════
PASSO 1: Calcular Dias Disponíveis
─────────────────────────────────────
Duração sprint: 10 dias (2 semanas)
Membros equipe: 5 desenvolvedores
Total pessoa-dias: 50 dias
PASSO 2: Subtrair Indisponibilidade
─────────────────────────────────────
Férias: -3 dias (@sarah, @mike)
Feriados: -0 dias
Treinamento: -2 dias (@lisa)
────────────────────────────
Disponível: 45 pessoa-dias
PASSO 3: Considerar Não-Codificação
─────────────────────────────────────
Reuniões (~15%): -6.75 dias
Suporte/bugs (~10%): -4.5 dias
────────────────────────────
Capacidade: 33.75 dias
PASSO 4: Converter para Pontos História
─────────────────────────────────────
Se 1 ponto ≈ 0.5 dia trabalho ideal
Capacidade ≈ 67 pontos história
PASSO 5: Aplicar Fator Histórico
─────────────────────────────────────
Velocidade média: 52 pontos
Últimos 3 sprints: 48, 55, 53
→ Alvo este sprint: 50-55 pontos
(conservador dado férias)
Reunião Planejamento Sprint
ESTRUTURA PLANEJAMENTO SPRINT
════════════════════════════
DURAÇÃO: 2-4 horas (para sprint 2 semanas)
PARTE 1: O QUE (60 min)
─────────────────────────────────────
Product owner apresenta:
├── Meta sprint
├── Principais prioridades do backlog
└── Contexto negócio
Equipe confirma:
├── Compreensão do trabalho
├── Questões respondidas
└── Trabalho está "pronto"
PARTE 2: QUANTO (45 min)
─────────────────────────────────────
Calcular capacidade:
├── Disponibilidade equipe
├── Compromissos conhecidos
└── Buffer para desconhecidos
Retirar do backlog:
├── Maior prioridade primeiro
├── Até capacidade atingida
└── Deixar 10-15% buffer
PARTE 3: COMO (45+ min)
─────────────────────────────────────
Para cada item:
├── Quebrar em subtarefas
├── Identificar dependências
├── Atribuir proprietários iniciais
└── Notar riscos/preocupações
SAÍDA:
├── Backlog sprint comprometido
├── Meta sprint clara
├── Atribuições tarefa iniciais
└── Riscos documentados
Estrutura Backlog no GitScrum
Visualização Backlog Sprint
VISUALIZAÇÃO BACKLOG SPRINT
═══════════════════════════
┌─────────────────────────────────────────────────────────┐
│ Sprint 23: Autenticação Usuário │
│ 18-29 Mar | Meta: Completar fluxo auth para mobile │
├─────────────────────────────────────────────────────────┤
│ Capacidade: 52 pts | Comprometido: 48 pts | Buffer: 8%│
├─────────────────────────────────────────────────────────┤
│ │
│ TODO (32 pts) EM PROGRESSO CONCLUÍDO │
│ ──────────── ─────────── ───── │
│ │
│ ┌────────────────┐ ┌──────────┐ │
│ │ API Login │ │ Reset │ │
│ │ 8 pts @mike │ │ senha │ │
│ │ Pronto ✓ │ │ 5 pts │ │
│ └────────────────┘ │ @sarah │ │
│ └──────────┘ │
│ ┌────────────────┐ │
│ │ Setup OAuth │ │
│ │ 5 pts @lisa │ │
│ │ Pronto ✓ │ │
│ └────────────────┘ │
│ │
│ ┌────────────────┐ │
│ │ UI Login Mobile│ │
│ │ 8 pts @tom │ │
│ │ Bloqueado: API │ │
│ └────────────────┘ │
│ │
│ ... mais itens ... │
│ │
└─────────────────────────────────────────────────────────┘
Quebra de Tarefa
EXEMPLO QUEBRA TAREFA
═════════════════════
HISTÓRIA: Implementação API Login (8 pts)
SUBTAREFAS:
├── Criar endpoint login (2 pts)
│ └── @mike, Dia 1-2
├── Implementar geração JWT (2 pts)
│ └── @mike, Dia 2-3
├── Adicionar rate limiting (1 pt)
│ └── @mike, Dia 3
├── Escrever testes unitários (2 pts)
│ └── @mike, Dia 4
└── Atualizar documentação API (1 pt)
└── @mike, Dia 4-5
DEPENDÊNCIAS:
├── Precisa: Modelo usuário (completo ✓)
├── Precisa: Biblioteca JWT (completa ✓)
└── Bloqueia: UI Login Mobile
CRITÉRIOS ACEITAÇÃO:
├── POST /api/login aceita email/senha
├── Retorna JWT em sucesso
├── Retorna 401 em credenciais inválidas
├── Rate limited para 5 tentativas/minuto
├── Trilha auditoria logada
└── Testes cobrem todos cenários
Gerenciando Backlog Sprint
Durante o Sprint
GERENCIAMENTO BACKLOG SPRINT
════════════════════════════
VERIFICAÇÕES DIÁRIAS:
├── Algum item bloqueado?
├── Itens levando mais que esperado?
├── Scope creep acontecendo?
├── Ainda no caminho para meta sprint?
AJUSTES MEIO-SPRINT:
├── Podemos enxamear em bloqueadores?
├── Precisamos cortar escopo?
├── Podemos adicionar trabalho se adiantados?
└── Comunicar mudanças
MUDANÇAS ESCOPO:
Se novo trabalho urgente aparece:
1. Avaliar urgência vs. trabalho atual
2. Se verdadeiramente urgente, o que sai?
3. Discutir com product owner
4. Documentar mudança
5. Comunicar para stakeholders
NUNCA:
├── Adicionar trabalho silenciosamente
├── Deixar scope creep acontecer
├── Perder meta sprint sem alertar cedo
└── Culpar equipe por fatores externos
Rastreamento Burndown
BURNDOWN SPRINT
═══════════════
Pontos restantes por dia:
48 │●
│ ●
40 │ ● ● (atraso)
│ ●
32 │ ●
│ ●
24 │ ●
│ ●
16 │ ●
│ ●
8 │ ●
│ ●
0 │──────────────────────────●
D1 D2 D3 D4 D5 D6 D7 D8 D9 D10
Legenda:
─── Burndown ideal
● Progresso atual
Status: No caminho após ajuste dia 4
Previsão: Completo com 2 pts buffer
Melhores Práticas
Para Backlogs Sprint
- Use dados velocidade — Não adivinhe capacidade
- Deixe buffer — 10-15% para desconhecidos
- Priorize impiedosamente — Itens top feitos primeiro
- Pronto significa pronto — Enforce Definição de Pronto
- Proteja o compromisso — Empurre adições
Anti-Padrões
ERROS BACKLOG SPRINT:
✗ Comprometer mais que velocidade
✗ Começar sprint com trabalho pouco claro
✗ Tarefas grandes demais para terminar
✗ Sem consideração dependências
✗ Adicionando trabalho meio-sprint sem remover
✗ Sem meta sprint
✗ Prioridades diferentes do que está no backlog
✗ Não rastreando progresso