8 min leitura • Guide 785 of 877
Melhores Práticas de Reunião de Refinamento
Bom refinamento torna o planejamento suave. GitScrum ajuda equipes a preparar itens de trabalho para que estejam prontos para serem puxados para sprints.
Propósito do Refinamento
Por Que Refinar
OBJETIVOS DO REFINAMENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ANTES DO REFINAMENTO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ STORY-456: Melhorar busca ││
│ │ ││
│ │ Descrição: Tornar busca melhor ││
│ │ Estimativa: ? ││
│ │ Pronta: ❌ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ APÓS O REFINAMENTO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ STORY-456: Adicionar autocomplete à busca ││
│ │ ││
│ │ Descrição: ││
│ │ Como usuário, quero sugestões de busca enquanto digito ││
│ │ para encontrar produtos mais rápido. ││
│ │ ││
│ │ Critérios de Aceite: ││
│ │ ☐ Sugestões aparecem após 3 caracteres ││
│ │ ☐ Máximo 5 sugestões mostradas ││
│ │ ☐ Navegação por teclado funciona ││
│ │ ☐ Funciona no mobile ││
│ │ ││
│ │ Notas Técnicas: ││
│ │ • Usar API de busca existente com matching de prefixo ││
│ │ • Debounce de 300ms ││
│ │ • Cache de consultas recentes ││
│ │ ││
│ │ Estimativa: 5 pontos ││
│ │ Dependências: Nenhuma ││
│ │ Pronta: ✅ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ RESULTADO: Equipe pode puxar para sprint com confiança │
└─────────────────────────────────────────────────────────────┘
Definition of Ready
PRONTA PARA SPRINT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ UMA HISTÓRIA ESTÁ PRONTA QUANDO: │
│ │
│ ENTENDIDA: │
│ ☐ Necessidade do usuário está clara │
│ ☐ Equipe entende o que construir │
│ ☐ Perguntas respondidas ou anotadas como suposições │
│ │
│ DEFINIDA: │
│ ☐ Critérios de aceite escritos │
│ ☐ Edge cases identificados │
│ ☐ Designs disponíveis (se trabalho de UI) │
│ │
│ ESTIMADA: │
│ ☐ Story points atribuídos │
│ ☐ Equipe concorda com estimativa │
│ ☐ Pequena o suficiente para completar no sprint │
│ │
│ INDEPENDENTE: │
│ ☐ Dependências identificadas │
│ ☐ Bloqueios resolvidos ou planejados │
│ ☐ Pode ser trabalhada sem esperar │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SE NÃO PRONTA: │
│ • Não puxe para sprint │
│ • Continue refinando │
│ • Ou crie spike para investigar │
└─────────────────────────────────────────────────────────────┘
Estrutura da Reunião
Sessão de Refinamento
FORMATO DA REUNIÃO DE REFINAMENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ LOGÍSTICA: │
│ Duração: 1-2 horas/semana │
│ Participantes: PO, Time de Dev, Scrum Master │
│ Frequência: Semanal ou duas vezes por semana │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ AGENDA: │
│ │
│ 1. REVISÃO (5 min) │
│ • Verificação rápida do backlog refinado │
│ • Alguma atualização desde última sessão? │
│ │
│ 2. DISCUTIR HISTÓRIAS (45-90 min) │
│ Para cada história: │
│ • PO apresenta necessidade do usuário (2 min) │
│ • Equipe faz perguntas (5-10 min) │
│ • Discute abordagem técnica (5 min) │
│ • Escreve/refina critérios de aceite (5 min) │
│ • Estima (5 min) │
│ │
│ 3. REVISAR DEPENDÊNCIAS (10 min) │
│ • Algum bloqueio identificado? │
│ • Necessidades cross-team? │
│ • Ações para resolver │
│ │
│ 4. ENCERRAMENTO (5 min) │
│ • Marque histórias como prontas │
│ • Anote itens de follow-up │
│ • Preview da próxima sessão │
│ │
│ META: 2-3 sprints de trabalho refinado no backlog │
└─────────────────────────────────────────────────────────────┘
Fluxo de Discussão
DISCUTINDO UMA HISTÓRIA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ HISTÓRIA: STORY-789 Adicionar notificações de usuário │
│ │
│ PO APRESENTA: │
│ ───────────── │
│ "Usuários querem ser notificados quando pedido é enviado. │
│ Atualmente precisam ficar verificando. Email está ok │
│ por agora, push notifications depois." │
│ │
│ PERGUNTAS DA EQUIPE: │
│ ───────────────────── │
│ P: "O que dispara a notificação?" │
│ R: "Quando status de envio muda no sistema de fulfillment"│
│ │
│ P: "Só enviado, ou todas mudanças de status?" │
│ R: "Começar só com enviado, adicionar outros depois" │
│ │
│ P: "Usuários podem optar por não receber?" │
│ R: "Sim, nas preferências. Padrão é receber." │
│ │
│ P: "Qual template de email?" │
│ R: "Design vai fornecer, segue estilo existente" │
│ │
│ DISCUSSÃO TÉCNICA: │
│ ───────────────────── │
│ Dev: "Vamos precisar escutar webhook do fulfillment" │
│ Dev: "Serviço de email já existe, só novo template" │
│ Dev: "Precisa adicionar preferências de notificação no │
│ modelo de usuário" │
│ │
│ CRITÉRIOS DE ACEITE: │
│ ───────────────────── │
│ ☐ Email enviado quando status do pedido = enviado │
│ ☐ Email contém número do pedido e link de rastreamento │
│ ☐ Usuário pode optar por não receber nas preferências │
│ ☐ Usuários que optaram não recebem emails │
│ │
│ ESTIMATIVA: 5 pontos │
│ STATUS: Pronta ✅ │
└─────────────────────────────────────────────────────────────┘
Dividindo Histórias
Splitting de Histórias
DIVIDINDO HISTÓRIAS GRANDES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ORIGINAL (Grande demais - 21 pontos): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ STORY-800: Sistema de notificações do usuário ││
│ │ ││
│ │ Usuários podem receber email e push notifications para ││
│ │ status de pedido, promoções e atividade da conta. ││
│ │ ││
│ │ Estimativa: 21 pontos (grande demais!) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DIVIDIDA POR FUNCIONALIDADE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ STORY-801: Email de pedido enviado (5 pts) ││
│ │ STORY-802: Email de pedido entregue (3 pts) ││
│ │ STORY-803: Preferências de notificação (5 pts) ││
│ │ STORY-804: Infraestrutura de push notification (8 pts) ││
│ │ STORY-805: Push notification para envio (5 pts) ││
│ │ STORY-806: Notificações de email promocional (5 pts) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ESTRATÉGIAS DE DIVISÃO: │
│ ───────────────────────── │
│ • Por etapa do workflow (criar → ler → atualizar → deletar)│
│ • Por tipo de usuário (admin, usuário, visitante) │
│ • Por canal (email, push, SMS) │
│ • Por happy path vs edge cases │
│ • Por must-have vs nice-to-have │
│ │
│ CADA HISTÓRIA DEVE: │
│ • Entregar valor ao usuário independentemente │
│ • Ser completável em um sprint │
│ • Ser testável por si só │
└─────────────────────────────────────────────────────────────┘
Problemas Comuns
Problemas de Refinamento
PROBLEMAS COMUNS DE REFINAMENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MUITO VAGO: │
│ ─────────── │
│ "Melhorar performance" │
│ "Tornar mais amigável para usuário" │
│ │
│ CORREÇÃO: Pergunte "Qual resultado específico usuário │
│ precisa?" Adicione critérios mensuráveis │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ MUITO DETALHADO: │
│ ────────────── │
│ 3 páginas de requisitos │
│ Cada botão descrito │
│ │
│ CORREÇÃO: Foque em critérios de aceite │
│ Deixe equipe descobrir implementação │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SOLUÇÃO PRESCRITA: │
│ ───────────────────── │
│ "Adicione um dropdown que..." │
│ "Use um modal para..." │
│ │
│ CORREÇÃO: Foque no problema, não na solução │
│ "Usuário precisa selecionar entre opções" │
│ Equipe decide melhor UX │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CONTEXTO FALTANDO: │
│ ───────────────── │
│ Sem designs para trabalho de UI │
│ Sem spec de API para integração │
│ │
│ CORREÇÃO: Bloqueie refinamento até contexto disponível │
│ PO prepara antes da reunião │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DISCUSSÃO INTERMINÁVEL: │
│ ──────────────────────── │
│ Time debate por 30 min │
│ Sem conclusão │
│ │
│ CORREÇÃO: Time-box discussões │
│ Não concordam? Crie spike para investigar │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Para Refinamento
- Prepare antecipadamente — PO traz contexto
- Time-box discussões — Não debata infinitamente
- Foque no porquê — Não apenas no como
- Mantenha pequeno — Divida histórias grandes
- Documente decisões — Capture em critérios de aceite
Anti-Padrões
ERROS DE REFINAMENTO:
✗ Refinando no planejamento de sprint
✗ PO dita soluções
✗ Sem critérios de aceite claros
✗ Histórias grandes demais
✗ Pulando estimativas
✗ Não identificando dependências
✗ Discussões sem time-box
✗ Sem backlog refinado de reserva