10 min leitura • Guide 52 of 877
Construindo Retrospectivas de Sprint Efetivas
Retrospectivas são a cerimônia mais subutilizada no agile. Bem feitas, elas compõem melhorias do time ao longo do tempo. Mal feitas, tornam-se sessões de reclamação que não mudam nada. GitScrum fornece a estrutura para executar retrospectivas que identificam problemas reais, geram melhorias acionáveis e rastreiam follow-through entre sprints.
O Problema da Retrospectiva
Por que a maioria das retrospectivas falha em criar mudança:
| Padrão Comum | Resultado |
|---|---|
| Mesmos problemas todo sprint | Nada se resolve, time perde fé |
| Desabafo sem soluções | Sente-se bem momentaneamente, sem melhoria |
| Ações desaparecem | Itens acordados nunca rastreados ou completados |
| Vozes mais altas dominam | Introvertidos e novos não contribuem |
| Sem dados, só sentimentos | Opiniões subjetivas sem evidência |
| Pular quando ocupado | Melhoria vira opcional |
Preparação da Retrospectiva
Coleta de Dados Antes da Reunião
COLETA DADOS PRÉ-RETROSPECTIVA:
┌─────────────────────────────────────────────────────────────┐
│ RESUMO MÉTRICAS SPRINT 24 │
├─────────────────────────────────────────────────────────────┤
│ │
│ VELOCIDADE & COMPLETUDE: │
│ ├── Comprometido: 42 pontos │
│ ├── Completado: 38 pontos (90%) │
│ ├── Carry over: 4 pontos (1 história) │
│ └── Tendência: ↓ de 95% sprint passado │
│ │
│ MÉTRICAS FLUXO: │
│ ├── Cycle time médio: 3.2 dias (↑ de 2.8) │
│ ├── Histórias bloqueadas: 4 (tempo bloqueado: 6 dias) │
│ └── Violações WIP: 2 ocasiões │
│ │
│ QUALIDADE: │
│ ├── Bugs encontrados no sprint: 3 │
│ ├── Bugs escaparam para prod: 1 │
│ └── Dívida técnica adicionada: 2 itens flagados │
│ │
│ INTERRUPÇÕES: │
│ ├── Trabalho não planejado: 5 pontos │
│ ├── Mudanças scope: 2 histórias modificadas │
│ └── Uso buffer: 80% │
│ │
│ SAÚDE TIME (pesquisa pulso): │
│ ├── Satisfação geral: 3.8/5 (↓ de 4.1) │
│ ├── Ritmo sustentável: 3.2/5 │
│ └── Clareza objetivos: 4.2/5 │
│ │
└─────────────────────────────────────────────────────────────┘
Pré-Coleta Async
INPUT RETRO ASYNC (GitScrum Discussions):
┌─────────────────────────────────────────────────────────────┐
│ 📝 Input Retrospectiva Sprint 24 │
│ Prazo: Sexta 16h (antes da retro 17h) │
├─────────────────────────────────────────────────────────────┤
│ │
│ Por favor adicionem pensamentos (opção anônima disponível): │
│ │
│ O QUE FOI BEM (continuar fazendo): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Pair programming na feature auth foi ótimo - @Kim ││
│ │ • Daily standups ficaram abaixo de 10 min - @Alex ││
│ │ • Sprint goal claro ajudou a priorizar - [anon] ││
│ │ • Boa colaboração com time de design - @Jordan ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ O QUE NÃO FOI BEM (parar ou mudar): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Bloqueados na spec API por 3 dias - @Sam ││
│ │ • Muitas reuniões na terça - [anon] ││
│ │ • História muito maior que estimado - @Kim ││
│ │ • Requisitos pouco claros na feature dashboard - @Pat ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ IDEIAS & EXPERIMENTOS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Tentar mob programming para histórias complexas ││
│ │ • Bloquear manhãs de terça para trabalho profundo ││
│ │ • Adicionar revisão contrato API ao DoR - @Sam ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Formatos de Retrospectiva
Formato Padrão (45-60 min)
AGENDA RETROSPECTIVA:
┌─────────────────────────────────────────────────────────────┐
│ TEMPO │ ATIVIDADE │
├───────┼─────────────────────────────────────────────────────┤
│ 5min │ ABERTURA │
│ │ • Revisar ações retro anterior │
│ │ • Compartilhar métricas sprint (sem julgamento) │
│ │ • Lembrete regras base │
│ │ │
│ 10min │ COLETAR DADOS │
│ │ • Revisar input async já enviado │
│ │ • Adicionar itens de última hora │
│ │ • Clarificar itens pouco claros │
│ │ │
│ 15min │ GERAR INSIGHTS │
│ │ • Votação por pontos em itens mais impactantes │
│ │ • Discutir top 2-3 itens profundamente │
│ │ • Identificar causas raiz, não só sintomas │
│ │ │
│ 15min │ DECIDIR AÇÕES │
│ │ • Converter insights em experimentos específicos │
│ │ • Atribuir owner para cada ação │
│ │ • Definir critérios sucesso e timeline │
│ │ │
│ 5min │ FECHAMENTO │
│ │ • Resumir ações acordadas │
│ │ • Feedback retro (como foi esta retro?) │
│ │ • Criar action items no GitScrum │
│ │
└─────────────────────────────────────────────────────────────┘
Formato Rápido (20 min)
RETROSPECTIVA RÁPIDA:
┌─────────────────────────────────────────────────────────────┐
│ PARA: Sprints curtos, times estáveis, períodos tranquilos │
├─────────────────────────────────────────────────────────────┤
│ │
│ 3min │ Status ações anteriores (rápido pass/fail) │
│ │
│ 5min │ Check-in uma palavra de cada pessoa │
│ │ "Descreva este sprint em uma palavra" │
│ │ Explicação rápida do porquê │
│ │
│ 7min │ Qual é a UMA coisa que devemos melhorar? │
│ │ Cada pessoa escreve uma sugestão │
│ │ Votação rápida, escolher item top │
│ │
│ 5min │ Definir ação para item top │
│ │ Quem, o quê, para quando │
│ │ Critérios de sucesso │
│ │
└─────────────────────────────────────────────────────────────┘
Análise de Causa Raiz
Técnica dos Cinco Por Quês
EXEMPLO: Por que não cumprimos o compromisso do sprint?
┌─────────────────────────────────────────────────────────────┐
│ ANÁLISE CINCO POR QUÊS │
├─────────────────────────────────────────────────────────────┤
│ │
│ SINTOMA: Não completamos a história do dashboard (4 pts) │
│ │
│ POR QUÊ 1: Por que não completamos? │
│ → "Ficamos sem tempo; era maior que estimado" │
│ │
│ POR QUÊ 2: Por que era maior que estimado? │
│ → "A API que precisávamos não estava pronta, tivemos que │
│ construir solução temporária" │
│ │
│ POR QUÊ 3: Por que a API não estava pronta? │
│ → "Time backend trabalhando em prioridade diferente" │
│ │
│ POR QUÊ 4: Por que não sabíamos dessa dependência? │
│ → "Não revisamos dependências no sprint planning" │
│ │
│ POR QUÊ 5: Por que não revisamos dependências no planning? │
│ → "Não temos checklist pra isso, e estávamos com pressa" │
│ │
│ CAUSA RAIZ: Falta revisão dependências no processo planning │
│ │
│ AÇÃO: Adicionar "check dependências" ao Definition of Ready │
│ Revisar dependências cross-team antes de comprometer │
│ │
└─────────────────────────────────────────────────────────────┘
Tracking de Ações
Framework de Experimento
ACTION ITEM COMO EXPERIMENTO:
┌─────────────────────────────────────────────────────────────┐
│ 🧪 EXPERIMENTO: SLA Revisão PR 24 Horas │
│ Melhoria Sprint 25 │
├─────────────────────────────────────────────────────────────┤
│ │
│ HIPÓTESE: │
│ "Se implementarmos SLA revisão PR de 24 horas, então │
│ cycle time diminuirá de 3.2 dias para 2.5 dias ou menos." │
│ │
│ OWNER: @Alex │
│ DURAÇÃO: 2 sprints (Sprint 25-26) │
│ │
│ CRITÉRIOS SUCESSO: │
│ ├── 90% PRs revisados dentro de 24 horas │
│ ├── Cycle time ≤ 2.5 dias │
│ └── Sem diminuição qualidade revisão │
│ │
│ IMPLEMENTAÇÃO: │
│ ├── Adicionar lembrete Slack para PRs abertos >12h │
│ ├── Time concorda revisar fila PR duas vezes ao dia │
│ ├── Limitar tamanho PR a <400 linhas de código │
│ └── Rastrear tempos revisão nas métricas sprint │
│ │
│ MEDIÇÃO: │
│ ├── Tempo revisão PR (métricas GitHub/GitLab) │
│ ├── Cycle time geral (analytics GitScrum) │
│ └── Bugs encontrados em code review vs. após merge │
│ │
│ PLANO ROLLBACK: │
│ Se time se sentir apressado ou qualidade cair, reverter e │
│ tentar solução alternativa. │
│ │
└─────────────────────────────────────────────────────────────┘
Board de Ações no GitScrum
TRACKING AÇÕES RETRO:
┌─────────────────────────────────────────────────────────────┐
│ 📋 Board Ações Retrospectiva │
├─────────────────────────────────────────────────────────────┤
│ │
│ A FAZER │ EM PROGRESSO │ FEITO (Este Trimestre) │
│ ──────────────┼─────────────────┼──────────────────────── │
│ │ │ │
│ Adicionar │ SLA PR 24h │ ✓ Timer daily standup │
│ check depend. │ @Alex │ (Sprint 22) │
│ ao DoR │ Sprint 25-26 │ │
│ @Sam │ │ ✓ Rotação pair │
│ Sprint 26 │ Bloquear terça │ programming (S23) │
│ │ manhãs │ │
│ Criar checklist @Jordan │ ✓ Opção standup │
│ revisão API │ Sprint 25 │ async (Sprint 23) │
│ @Pat │ │ │
│ Sprint 26 │ │ │
│ │
│ LABELS: │
│ 🔴 Vencido | 🟡 Em Risco | 🟢 Em Dia │
│ │
│ MÉTRICAS: │
│ ├── Ações criadas este trimestre: 12 │
│ ├── Ações completadas: 8 (67%) │
│ └── Ações vencidas: 2 │
│ │
└─────────────────────────────────────────────────────────────┘
Técnicas de Facilitação
Garantindo Participação
FACILITAÇÃO INCLUSIVA:
┌─────────────────────────────────────────────────────────────┐
│ TÉCNICAS PARA PARTICIPAÇÃO BALANCEADA │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. ESCRITA SILENCIOSA PRIMEIRO │
│ Todos escrevem pensamentos antes da discussão │
│ Previne que vozes altas ancorem │
│ │
│ 2. COMPARTILHAR ROUND-ROBIN │
│ Cada pessoa compartilha um item na vez │
│ Sem interrupções durante turno de alguém │
│ Opção de passar disponível │
│ │
│ 3. OPÇÃO INPUT ANÔNIMO │
│ Permitir envio anônimo para temas sensíveis │
│ GitScrum Discussion comentários anônimos habilitados │
│ │
│ 4. VOTAÇÃO POR PONTOS │
│ Todos têm votos iguais (ex: 3 pontos) │
│ Votação silenciosa previne influência │
│ │
│ 5. BREAKOUTS GRUPOS PEQUENOS │
│ Grupos 2-3 pessoas para discussão profunda │
│ Introvertidos frequentemente mais confortáveis │
│ │
│ 6. ROTACIONAR FACILITADOR │
│ Pessoa diferente lidera cada retro │
│ Perspectivas frescas, ownership compartilhado │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Fazer
RETROSPECTIVAS EFETIVAS:
✓ PREPARAR COM DADOS
Trazer métricas, não só opiniões
✓ CRIAR SEGURANÇA
Opções anônimas, sem culpa, olhando pra frente
✓ FOCAR EM POUCAS AÇÕES
2-3 ações bem executadas > 10 esquecidas
✓ FAZER AÇÕES ESPECÍFICAS
Owner, timeline, critérios sucesso, rastreado no GitScrum
✓ DAR FOLLOW-UP
Revisar ações anteriores, celebrar completadas
✓ VARIAR O FORMATO
Manter fresco, combinar formato com situação
✓ PROTEGER O TEMPO
Nunca pular retros, mesmo quando ocupado
Não Fazer
ANTI-PADRÕES RETROSPECTIVA:
✗ CULPAR INDIVÍDUOS
Focar em processo, não pessoas
✗ SÓ FALAR, SEM AÇÃO
Se não pode se comprometer, não aceite
✗ MANAGER DOMINA
Criar espaço para vozes do time
✗ IGNORAR REPETIÇÃO
Mesmo issue = solução anterior não funcionou
✗ CORRER
Discussão de qualidade > marcar caixinha