Melhores Práticas de Sprint Review

Sprint review é onde o time demonstra o que construiu. Não é uma reunião de status—é uma sessão de feedback. Uma boa review mostra software funcionando, coleta input real de stakeholders e constrói confiança na entrega do time. Uma ruim é uma apresentação de slides que ninguém se importa.

Propósito da Review

Preparação

Antes da Review

PREPARAÇÃO DO SPRINT REVIEW
═══════════════════════════

PREP DO TIME (1-2 horas antes):
─────────────────────────────────────
□ Identificar o que demonstrar
  ├── Stories completadas (Definition of Done atendido)
  ├── Ordem de prioridade para demo
  ├── Pular: Trabalho incompleto, tarefas técnicas
  └── Foco: Valor visível ao usuário

□ Preparar ambiente de demo
  ├── Dados frescos/contas de teste
  ├── Ambiente funcionando (staging)
  ├── Plano backup se demo falhar
  └── Testar o fluxo da demo

□ Atribuir responsabilidades de demo
  ├── Quem demonstra o que
  ├── Quem lida com perguntas
  └── Ordem de apresentações

□ Preparar contexto
  ├── Lembrete da meta do sprint
  ├── O que comprometemos vs. completamos
  ├── Decisões chave tomadas
  └── Bloqueios encontrados

PREP DO PO:
─────────────────────────────────────
□ Convidar stakeholders
  ├── Quem precisa ver isso?
  ├── Quem pode fornecer feedback?
  ├── Enviar agenda
  └── Confirmar presença

□ Preparar pontos de discussão
  ├── Próximas prioridades
  ├── Perguntas para stakeholders
  ├── Mudanças de backlog para discutir
  └── Contexto do roadmap

Planejamento da Demo

ESTRUTURA DA DEMO
═════════════════

FORMATO:
─────────────────────────────────────
Tempo total: 60 minutos (sprint de 2 semanas)

├── Boas-vindas & Contexto (5 min)
│   ├── Meta do sprint
│   ├── Quem está aqui
│   └── O que vamos mostrar
│
├── Demo de Software Funcionando (30-40 min)
│   ├── Feature 1: [quem demonstra]
│   ├── Feature 2: [quem demonstra]
│   ├── Feature 3: [quem demonstra]
│   └── Perguntas durante cada
│
├── Discussão (15-20 min)
│   ├── Feedback de stakeholders
│   ├── Próximas prioridades
│   ├── Implicações no backlog
│   └── Perguntas e respostas
│
└── Encerramento (5 min)
    ├── Decisões chave capturadas
    ├── Preview do próximo sprint
    └── Agradecimentos

ORDEM DA DEMO:
─────────────────────────────────────
Lidere com impacto:
├── Feature mais valiosa primeiro
├── Mais interessante para stakeholders
├── Constrói credibilidade
└── Se tempo encurtar, você mostrou o melhor

Pular:
├── Refatoração interna (a menos que stakeholder se importe)
├── Correções de bugs (mencionar brevemente se significativo)
├── Trabalho incompleto (nunca demonstre meio-feito)
└── Detalhes técnicos (a menos que audiência queira)

Executando a Review

Demos Efetivas

MELHORES PRÁTICAS DE DEMO
═════════════════════════

MOSTRAR, NÃO CONTAR:
─────────────────────────────────────
Não: "Implementamos a feature de busca"
Sim: [Realmente buscar por algo]
     "Aqui está o que acontece quando um usuário busca..."

Software ao vivo > Screenshots > Slides
(Nessa ordem de preferência)

PERSPECTIVA DO USUÁRIO:
─────────────────────────────────────
Enquadre como ação do usuário:
"Como cliente, agora posso..."
"Sara precisa encontrar seus pedidos, então ela..."
"Isso resolve o problema onde usuários não podiam..."

Não:
"Adicionamos um endpoint que..."
"O banco de dados agora suporta..."

CENÁRIOS REAIS:
─────────────────────────────────────
Use dados realistas:
├── Nomes de usuário que parecem reais
├── Cenários realistas
├── Edge cases se relevantes
├── Não "teste123" em todo lugar
└── Stakeholders se veem

LIDAR COM FALHAS:
─────────────────────────────────────
Se demo quebrar:
├── Fique calmo
├── Reconheça
├── Siga em frente ou use backup
├── "Funcionou nos testes—vamos investigar"
└── Não desperdice tempo de reunião debugando

Coletando Feedback

COLETA DE FEEDBACK
══════════════════

FAÇA PERGUNTAS:
─────────────────────────────────────
Após cada feature:
├── "O que você acha?"
├── "Isso resolve sua necessidade?"
├── "O que está faltando?"
├── "Como você usaria isso?"
└── Realmente ouça as respostas

NÃO:
├── Perguntar "Alguma pergunta?" (recebe silêncio)
├── Defender imediatamente
├── Prometer corrigir tudo
├── Descartar feedback

CAPTURE FEEDBACK:
─────────────────────────────────────
Designe quem toma notas:
├── Feedback dado
├── Quem disse
├── Action items
├── Implicações no backlog
└── Adicionar ao GitScrum depois

TIPOS DE FEEDBACK:
─────────────────────────────────────
Validar:
├── "Sim, isso é exatamente o que precisávamos"
└── Confiança para continuar

Ajustar:
├── "Bom, mas poderíamos também..."
└── Adições menores a considerar

Pivotar:
├── "Na verdade, o problema real é..."
└── Aprendizado maior, mudanças no backlog

Questionar:
├── "E o edge case X?"
└── Pode precisar mais trabalho ou clarificação

Melhores Práticas

Para Sprint Reviews

1. Software funcionando — Não slides
2. Demo preparada — Testar antes
3. Feedback interativo — Não monólogo
4. Stakeholders certos — Quem se importa
5. Timebox — 1 hora máximo

Anti-Padrões

ERROS DE SPRINT REVIEW:
✗ Apresentação de slides
✗ Demo não preparada/quebra
✗ Sem stakeholders presentes
✗ Monólogo sem interação
✗ Demonstrar trabalho incompleto
✗ Detalhes técnicos demais
✗ Não coletar feedback
✗ Não atualizar backlog depois

Soluções Relacionadas

• Melhores práticas de sprint planning
• Melhores práticas de demo de sprint
• Engajamento de stakeholders