7 min leitura • Guide 543 of 877
Gerenciando Refinamento do Sprint Backlog
Refinamento de backlog bem feito faz sprint planning mais rápido, reduz surpresas mid-sprint e melhora precisão de estimativas. Sessões focadas de refinamento preparam itens para estarem verdadeiramente prontos para entrar no sprint.
Objetivos do Refinement
| Objetivo | Indicador | Benefício |
|---|---|---|
| Pronto para sprint | Atende DoR | Planning mais rápido |
| Bem estimado | Consenso do time | Velocidade previsível |
| Tamanho certo | Tarefas de 1-3 dias | Trabalho gerenciável |
| Priorizado | Stack-ranked | Foco claro |
| Entendido | Perguntas respondidas | Menos confusão mid-sprint |
Processo de Refinement
WORKFLOW DE REFINAMENTO DE BACKLOG
══════════════════════════════════
ANTES DA SESSÃO (PO + Tech Lead):
┌─────────────────────────────────────────────────┐
│ 1. Revisar requisições chegando │
│ 2. Rascunhar user stories com acceptance │
│ criteria │
│ 3. Identificar itens que precisam input técnico│
│ 4. Pré-priorizar itens para discussão │
│ 5. Marcar itens com dependências ou riscos │
│ │
│ Tempo: 1-2 horas antes da sessão semanal │
└─────────────────────────────────────────────────┘
│
▼
SESSÃO DE REFINEMENT (Time Completo):
┌─────────────────────────────────────────────────┐
│ Duração: 1 hora por semana │
│ │
│ Agenda: │
│ 1. Revisar novos itens (15 min) │
│ └── PO apresenta, time pergunta │
│ │
│ 2. Clarificar itens existentes (20 min) │
│ └── Responder perguntas abertas │
│ │
│ 3. Estimar itens prontos (20 min) │
│ └── Planning poker ou similar │
│ │
│ 4. Identificar riscos/dependências (5 min) │
│ └── Marcar para follow-up │
└─────────────────────────────────────────────────┘
│
▼
APÓS SESSÃO (Contínuo):
┌─────────────────────────────────────────────────┐
│ 1. Atualizar stories com clarificações │
│ 2. Pesquisar questões técnicas marcadas │
│ 3. Resolver dependências │
│ 4. Dividir stories se muito grandes │
│ 5. Manter backlog priorizado │
└─────────────────────────────────────────────────┘
Definição de Ready
DEFINITION OF READY (DoR)
═════════════════════════
ANTES DE ENTRAR NO SPRINT, ITEM DEVE TER:
CLAREZA:
☐ User story segue formato (Como... Quero... Para que...)
☐ Critérios de aceitação específicos e testáveis
☐ Designs de UI anexados (se aplicável)
☐ Abordagem técnica entendida
TAMANHO:
☐ Estimado pelo time
☐ Pode ser completado em 1-3 dias
☐ Se maior, quebrado em sub-tarefas
DEPENDÊNCIAS:
☐ Sem dependências bloqueantes, OU
☐ Dependências agendadas para completar primeiro
☐ Dependências externas têm timeline
PRIORIDADE:
☐ Product Owner priorizou
☐ Alinhamento com stakeholders confirmado
TESTABILIDADE:
☐ Cenários de teste identificados
☐ Edge cases documentados
Guia de Sizing de Stories
REFERÊNCIA DE SIZING DE STORY
═════════════════════════════
1 PONTO - Trivial:
┌─────────────────────────────────────────────────┐
│ • Mudança de configuração │
│ • Atualização de texto │
│ • Bug fix simples com causa conhecida │
│ Tempo: < 4 horas │
└─────────────────────────────────────────────────┘
2 PONTOS - Pequena:
┌─────────────────────────────────────────────────┐
│ • Adicionar campo a formulário existente │
│ • Endpoint simples de API │
│ • Componente básico de UI │
│ Tempo: 4-8 horas (meio dia a dia inteiro) │
└─────────────────────────────────────────────────┘
3 PONTOS - Média:
┌─────────────────────────────────────────────────┐
│ • Feature com alguns componentes │
│ • CRUD completo para uma entidade │
│ • Integração com serviço existente │
│ Tempo: 1-2 dias │
└─────────────────────────────────────────────────┘
5 PONTOS - Grande:
┌─────────────────────────────────────────────────┐
│ • Feature cross-cutting │
│ • Múltiplos componentes coordenados │
│ • Integração com serviço novo │
│ Tempo: 2-3 dias │
│ CONSIDERE: Dividir se possível │
└─────────────────────────────────────────────────┘
8+ PONTOS - Muito Grande:
┌─────────────────────────────────────────────────┐
│ • Deve ser dividida │
│ • Incerteza muito alta │
│ • Spike primeiro para descobrir │
└─────────────────────────────────────────────────┘
Técnicas de Estimativa
Planning Poker
PLANNING POKER:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PROCESSO: │
│ ────────── │
│ 1. PO apresenta a story │
│ 2. Time faz perguntas de clarificação │
│ 3. Cada pessoa escolhe carta (em segredo) │
│ 4. Revelar simultaneamente │
│ 5. Discutir divergências │
│ 6. Re-votar se necessário │
│ 7. Consenso = estimativa final │
│ │
│ CARTAS: 1, 2, 3, 5, 8, 13, 21, ? │
│ │
│ QUANDO DIVERGE MUITO: │
│ • Pessoa mais alta explica por quê │
│ • Pessoa mais baixa explica por quê │
│ • Frequentemente há info faltando │
│ • Clarificar e re-votar │
│ │
│ DICA: ? = "não sei estimar, preciso mais info" │
│ │
└─────────────────────────────────────────────────────────────┘
T-Shirt Sizing
T-SHIRT SIZING (alternativa mais rápida):
┌─────────────────────────────────────────────────────────────┐
│ │
│ TAMANHOS: │
│ ────────── │
│ P (Pequeno) = 1-2 pontos = < 1 dia │
│ M (Médio) = 3-5 pontos = 1-2 dias │
│ G (Grande) = 8 pontos = 2-3 dias │
│ GG (Extra) = 13+ pontos = Dividir │
│ │
│ QUANDO USAR: │
│ • Refinement rápido │
│ • Backlog grande para estimar │
│ • Time prefere simplicidade │
│ │
│ CONVERTER PARA PONTOS: │
│ Se precisar de números para velocity: │
│ P=2, M=3, G=5, GG=8 (média do range) │
│ │
└─────────────────────────────────────────────────────────────┘
Preparação de Stories
Checklist de Qualidade
CHECKLIST DE STORY BEM ESCRITA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TÍTULO: │
│ ☐ Ação clara (verbo no início) │
│ ☐ Conciso mas descritivo │
│ │
│ DESCRIÇÃO: │
│ ☐ Formato: Como [usuário] quero [ação] para que [valor] │
│ ☐ Contexto de negócio │
│ ☐ Links para designs/specs │
│ │
│ ACCEPTANCE CRITERIA: │
│ ☐ Específicos e testáveis │
│ ☐ Cobrem cenário principal │
│ ☐ Incluem edge cases importantes │
│ ☐ Formato: "Dado [contexto], quando [ação], então [result]"│
│ │
│ TÉCNICO: │
│ ☐ Abordagem discutida/entendida │
│ ☐ Dependências identificadas │
│ ☐ Riscos conhecidos documentados │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Checklist de Implementação
CHECKLIST DE REFINEMENT
═══════════════════════
PREPARAÇÃO:
☐ PO prepara itens antes da sessão
☐ Tech lead revisa questões técnicas
☐ Itens priorizados para discussão
☐ Sala/call reservada
SESSÃO:
☐ Timeboxed (1h máx)
☐ Agenda seguida
☐ Foco em clarificação
☐ Estimativas com consenso
☐ Riscos identificados
APÓS:
☐ Stories atualizadas
☐ Questões pendentes atribuídas
☐ Dependências resolvidas
☐ Backlog re-priorizado
QUALIDADE:
☐ DoR aplicado
☐ Stories passam checklist
☐ Tamanho apropriado
☐ Time confia nas estimativas
MÉTRICAS:
☐ % stories que atendem DoR
☐ Stories que precisam re-refinement
☐ Variação entre estimativa e real
Refinement bem feito é investimento—tempo gasto clarificando antes economiza tempo resolvendo durante o sprint.