Sprint retrospective: guia completo — 24 atividades e jogos de retro + modelo de pauta

A sprint retrospective é a reunião de balanço que um time Scrum faz ao fim de cada sprint para examinar como o trabalho foi feito — o que deu certo, o que falhou e qual única coisa melhorar no próximo sprint. Ela avalia "como trabalhamos"; a sprint review avalia "o que construímos".

A versão de 30 segundos

Frequência: uma vez no fim de cada sprint, logo depois da sprint review;

Duração: sprint de duas semanas → 60–90 minutos; sprint de uma semana → 45 minutos;

Resultado: 1–2 ações de melhoria com responsável nomeado e critério de conclusão verificável (não uma pilha de "sejamos mais cuidadosos na próxima");

Sinal de saúde: se as ações de três retrospectivas seguidas aterrissaram de verdade, o processo está melhorando de verdade.

Pauta padrão (versão de 60 minutos)

Tempo	Etapa	Propósito
0:00–0:05	Abertura e aquecimento	Marcar o tom: ambiente seguro, fatos e não pessoas
0:05–0:15	Coletar dados	Todos anotam fatos e sentimentos do sprint (com os quadros de atividade abaixo)
0:15–0:30	Gerar insights	Agrupar e votar; trazer à tona os 1–3 temas mais importantes
0:30–0:50	Decidir ações	Transformar temas em ações concretas: quem faz o quê e o que conta como pronto
0:50–0:60	Fechamento	Revisar as ações da última reunião, confirmar que as desta entram no quadro

O maior modo de fracasso da retrospectiva não é o silêncio constrangedor — é "baita conversa, e ninguém acompanha as ações". Ações vão para o quadro do sprint e são tratadas como qualquer outro item de trabalho.

24 atividades e jogos de retrospectiva

A. Estruturas clássicas (de sobra para a rotação do dia a dia)

Start / Stop / Continue: o que começar, parar e continuar a fazer. O mais simples e universal, serve para qualquer time;

4Ls: Liked, Learned, Lacked, Longed for;

Mad / Sad / Glad: orientado a emoções, bom para expor problemas de moral;

Veleiro (Sailboat): vento = vento a favor, âncora = freio, rochas = riscos, ilha = objetivo. Bem visual; cabe em marcos de projeto;

KPT: Keep / Problem / Try; comum em times de estilo japonês, estrutura limpa.

B. Atividades focadas em qualidade

Mapa de defeitos: agrupar na parede os defeitos do sprint por módulo e achar a olho nu as zonas de desastre; discutir se é problema de design ou de processo;

Linha do tempo do retrabalho: listar cada tarefa interrompida ou refeita e perseguir a causa raiz (requisito confuso? ambiente instável? relatório sem contexto?);

Um bug memorável: cada um conta o defeito mais absurdo do sprint e sua causa raiz — muito mais eficaz que discussão abstrata.

C. Jogos quebra-gelo para animar (a categoria dos "retro games")

Duas verdades e uma mentira: cada um conta três coisas que aconteceram neste sprint, uma é mentira; os outros adivinham;

Boletim meteorológico de emojis: resuma seu sprint com emojis;

Roleta do falador: sortear ao acaso o próximo a falar, para não serem sempre os mesmos;

Máquina do tempo: imagine olhar o projeto de hoje daqui a um ano, e escreva uma carta para o time atual.

D. Caçadores de causa raiz

5 Porquês: encadear cinco "porquês" sobre o problema mais votado;

Diagrama de espinha de peixe: atribuir causas entre pessoas, processo, ferramentas e ambiente;

Pre-mortem: suponha que o próximo sprint fracassou; escreva antes o "relatório do fracasso" e retroceda até o que é preciso prevenir.

E. Para times remotos

Post-its em quadro branco online: o clássico de três colunas (FunRetro / EasyRetro / Miro), notas anônimas + votação;

Escrita silenciosa e depois discussão: cada um escreve sozinho por 3 minutos primeiro, e depois os itens são passados — evita a ancoragem no primeiro falante;

Voto térmico: cada um tem 3 votos para os post-its que mais quer discutir; só os 2 primeiros entram em discussão;

Por turnos e por grupos: times grandes discutem primeiro em grupos pequenos (breakout rooms), depois se juntam e apresentam.

F. Variações para manter a frescura

Dar nota ao sprint: atribuir uma nota de 1 a 10 e explicar por que ela não é mais alta;

Checagem de meta: fixar o Sprint Goal na parede e discutir a contribuição real de cada trabalho para a meta;

Troca de papéis: os desenvolvedores falam pelo PO, o PO fala pelo QA — dois minutos cada;

Círculo de agradecimento: cada um agradece publicamente a um colega por uma ajuda específica; bom fechamento, conserta o ânimo;

Microexperimentos: empacotar as ações como experimentos: "testar X neste sprint, e na próxima retro decidir com os dados se fica". Menos pressão de compromisso, mais fácil de aterrissar.

Como escrever ações que ninguém esquece

Ruim	Bom
"Reforçar os testes"	"Percorrer a checklist de release antes de cada publicação, executada pelo QA de sobreaviso da semana; checar o índice de cumprimento nas duas próximas retros"
"Reduzir a comunicação inútil"	"Relatórios de bug passam só pelo registro compartilhado; no chat cola o link sem descrever o problema; blitz na próxima quarta"
"Melhorar a qualidade do código"	"Adicionar hook de lint pré-commit, configurado pelo responsável do backend até sexta"

Rasgo comum: responsável nomeado, prazo e critério de conclusão verificável.

Sustente a retro com dados, não com impressões

"Este sprint a qualidade foi ruim" — conclusões impressionistas assim só provocam defesas. Deixe os dados quantificados falarem:

Total de defeitos do sprint, por módulo e severidade;

Tempo médio de correção por defeito, número de idas e vindas;

Origem dos defeitos (testes internos / reportes de usuários beta / reportes de usuários em produção).

Esses números precisam de um registro de defeitos único — não de arqueologia em logs de chat. Os relatórios do BugCapturer chegam com anotações de captura e erros Console/Network (veja a função de diagnóstico) e são enviados automaticamente a um canal do Slack / Microsoft Teams como ponto único de acompanhamento; uma tabela dinâmica por módulo/severidade/status produz os números acima — exporte uma tabela antes da retro e a matéria-prima do mapa de defeitos (atividade 6) e da linha do tempo do retrabalho (atividade 7) está pronta.

FAQ

P: Qual é o propósito da sprint retrospective? R: Melhorar continuamente a forma de trabalho do time. O Scrum Guide é explícito: o resultado é um plano de melhoria executável, não um simples desabafo. P: Retrospective vs Review — qual a diferença? R: A Review apresenta o incremento do produto aos stakeholders; a Retrospective examina o processo de colaboração (só o time). As duas são necessárias; não funda as duas. P: Com só 3 pessoas, vale a pena fazer a retro? R: Vale — encurte para 30 minutos: 5 de coleta, 10 de votação, 15 de ações. Times pequenos mudam de processo mais rápido, então o ganho é ainda maior. P: Os mesmos problemas sempre voltam, o que fazer? R: Significa que as ações não aterrissam ou não têm responsável. A próxima retro começa revisando publicamente o índice de cumprimento das ações anteriores; se preciso, coloque "ações de melhoria aterrissadas" na Definition of Done. P: Reclamações demais, clima pesado — como lidar? R: Feche sempre com algo positivo: círculo de agradecimento ou nota do sprint. E garanta que cada retro produza pelo menos uma conclusão de "continuar fazendo" — retro não é tribunal.

Extensão do navegador

Incorpore o Web SDK

Compartilhar link

Contexto automático

Equipes e membros

Projetos e domínios