4 min leitura • Guide 786 of 877
Técnicas de Retrospectiva de Sprint
Retrospectivas transformam experiência em melhoria. GitScrum ajuda times a capturar resultados de retro e rastrear itens de ação para crescimento contínuo.
Formatos de Retrospectiva
Start-Stop-Continue
FORMATO START-STOP-CONTINUE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Retrospectiva Sprint 12 │
│ │
│ COMEÇAR (Coisas para tentar) │
│ ─────────────────────────── │
│ • Updates assíncronos diários em vez de standups │
│ • Pair programming para features complexas │
│ • Reviews de design antes da implementação │
│ │
│ PARAR (Coisas não funcionando) │
│ ────────────────────────────── │
│ • Puxar trabalho no meio do sprint │
│ • Pular code reviews para "correções rápidas" │
│ • Reuniões de planning longas (3+ horas) │
│ │
│ CONTINUAR (Coisas funcionando bem) │
│ ──────────────────────────────────── │
│ • Sexta-feira dia de bug fix │
│ • Critérios de aceite claros nas stories │
│ • Spikes técnicos para incógnitas │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ VOTAÇÃO: Cada pessoa tem 3 votos │
│ Discuta itens mais votados │
│ Crie 2-3 itens de ação │
└─────────────────────────────────────────────────────────────┘
O Que Foi Bem - O Que Não Foi - Ideias
FORMATO 4Ls:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Retrospectiva Sprint 12 │
│ │
│ GOSTOU (O que foi bem) │
│ ─────────────────────── │
│ • Ótima colaboração do time │
│ • Cumpriu todos os compromissos do sprint │
│ • Novo membro rampou rápido │
│ • Comunicação clara com PO │
│ │
│ APRENDEU (O que aprendemos) │
│ ────────────────────────── │
│ • React Query simplifica data fetching │
│ • Precisamos estimar trabalho de API com mais cuidado │
│ • PRs pequenos são revisados mais rápido │
│ │
│ FALTOU (O que estava faltando) │
│ ────────────────────────────── │
│ • Documentação para novo serviço │
│ • Tempo de QA antes do fim do sprint │
│ • Definição clara de pronto │
│ │
│ DESEJOU (O que gostaríamos de ter) │
│ ──────────────────────────────── │
│ • Testes E2E automatizados │
│ • Melhor ambiente de staging │
│ • Mais tempo para refatoração │
│ │
│ AÇÕES: │
│ 1. Adicionar testes E2E para caminhos críticos │
│ 2. Reservar último dia para QA │
│ 3. Criar template de checklist de DoD │
└─────────────────────────────────────────────────────────────┘
Mad-Sad-Glad
FORMATO MAD-SAD-GLAD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Retrospectiva Sprint 12 │
│ │
│ 😠 BRAVO (Frustrações) │
│ ─────────────────────── │
│ • Build quebrou múltiplas vezes │
│ • Requisitos mudaram no meio do sprint │
│ • Bloqueado esperando dependências │
│ │
│ 😢 TRISTE (Decepções) │
│ ──────────────────────── │
│ • Não terminamos a feature de dashboard │
│ • Tivemos que cortar cantos em testes │
│ • Menos tempo para aprendizado │
│ │
│ 😊 FELIZ (Celebrações) │
│ ──────────────────────── │
│ • Entregamos feature de pagamento no prazo │
│ • Ótima colaboração entre times │
│ • Zero incidentes em produção │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ FOCO DA DISCUSSÃO: │
│ │
│ Itens "BRAVO" geralmente têm causas raiz │
│ Pergunte: "Por que isso aconteceu?" │
│ Pergunte: "O que podemos fazer diferente?" │
│ │
│ Itens "TRISTE" frequentemente refletem gaps de processo │
│ Pergunte: "O que nos impediu?" │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Para Técnicas de Retro
- Segurança primeiro — Ambiente sem julgamento
- Estrutura ajuda — Use formato consistente
- Ação necessária — Sempre saia com itens
- Acompanhe — Revise ações anteriores
- Varie formato — Evite monotonia
Anti-Padrões
ERROS DE RETROSPECTIVA:
✗ Sem segurança psicológica
✗ Nenhuma ação tomada
✗ Não revisar ações anteriores
✗ Sempre mesmo formato
✗ Muito tempo/muito curto
✗ Foco em culpar
✗ Pular quando "ocupado"
✗ Dominada por uma pessoa