Review × Retro: a diferença (e por que ter as duas)
Sprint review e retrospectiva não são a mesma reunião: uma olha o produto com stakeholders, a outra o processo só com o time. Veja formato e exemplos.
Review e retro: o que cada uma é (e o que cada uma olha)
Sprint review e retrospectiva são as duas cerimônias de fechamento de uma sprint — e, apesar de acontecerem quase juntas, respondem a perguntas completamente diferentes. A review olha o produto: o time apresenta o que foi entregue no ciclo para os stakeholders (clientes internos, gestores de outras áreas, patrocinadores) e colhe feedback sobre o resultado. A pergunta central é "entregamos a coisa certa?". A retrospectiva olha o processo: só o time, sem gente de fora, conversa sobre como foi trabalhar naquele ciclo — o que ajudou, o que atrapalhou, o que vai mudar na próxima sprint. A pergunta central é "estamos trabalhando do jeito certo?".
Uma forma simples de gravar: a review inspeciona o que foi feito; a retro inspeciona como foi feito. Na review, o protagonista é a entrega e o convidado é o stakeholder. Na retro, o protagonista é o time e a porta fica fechada. As duas terminam gerando ajustes — a review ajusta o backlog (o que construir a seguir), a retro ajusta o jeito de trabalhar (acordos, ferramentas, comunicação).
Por serem vizinhas no calendário, muita equipe acaba tratando as duas como uma coisa só — "a reunião de fim de sprint". É aí que mora o problema que este artigo destrincha: quando review e retro se fundem, uma sempre engole a outra, e o time perde ou o alinhamento com quem paga a conta, ou o espaço seguro para melhorar de verdade.
A diferença lado a lado
Antes dos detalhes, o contraste direto:
| Sprint review | Retrospectiva | |
|---|---|---|
| Foco | O produto: o que foi entregue | O processo: como o time trabalhou |
| Pergunta | Entregamos a coisa certa? | Estamos trabalhando bem juntos? |
| Quem participa | Time + stakeholders | Só o time |
| Tom | Demonstração e conversa sobre valor | Conversa franca, às vezes desconfortável |
| Saída típica | Backlog ajustado, próximas prioridades | 1 a 3 ações de melhoria do processo |
| Clima | Vitrine: mostrar e ouvir | Bastidor: abrir e resolver |
Repare que nenhuma linha da tabela se sobrepõe. Não é uma questão de estilo ou preferência — são reuniões com públicos, assuntos e saídas diferentes. É por isso que o Scrum define as duas como eventos separados, e não como dois blocos da mesma agenda.
O que acontece quando o time junta as duas
A tentação é compreensível: "já estamos todos reunidos no fim da sprint, vamos resolver tudo de uma vez". Na prática, a fusão produz três estragos previsíveis.
1. A demo engole a melhoria. Demonstrar o que foi entregue é concreto, tem slides, tem tela compartilhada, gera perguntas dos stakeholders. A conversa sobre processo é abstrata e desconfortável. Quando as duas disputam a mesma hora, a review consome 50 minutos e a retro vira "alguém tem algo a dizer? Não? Ótimo, até a próxima". O time passa meses sem melhorar nada, e nem percebe, porque tecnicamente "fez a retro".
2. O time se cala. Retrospectiva boa depende de o time falar o que dói: "a prioridade mudou três vezes e ninguém avisou", "fulano centraliza tudo e vira gargalo", "prometemos demais de novo". Ninguém fala isso com o diretor da outra área na sala — nem com o cliente interno que causou a mudança de prioridade. Com stakeholder presente, a retro vira teatro: todo mundo elogia, ninguém expõe, e os problemas reais continuam intactos. Segurança psicológica não sobrevive a plateia errada.
3. O stakeholder se perde. O inverso também acontece: o convidado veio ver o resultado e assiste ao time discutir se a daily deveria mudar de horário ou se o quadro precisa de uma coluna nova. Ele sai achando a reunião improdutiva e, na sprint seguinte, não aparece — e aí a review perde o que tem de mais valioso, que é o feedback de quem usa a entrega.
O resultado combinado é cruel: a reunião única falha nos dois objetivos ao mesmo tempo. Nem o produto recebe feedback honesto, nem o processo melhora.
O formato de uma boa review
A review é a vitrine da sprint. Um formato que funciona em 45–60 minutos:
- Contexto (5 min). Quem conduz relembra o objetivo da sprint: o que o time se propôs a entregar e por quê.
- Demonstração (20–30 min). O time mostra o que ficou pronto — funcionando, não em slides sobre o que vai funcionar. Cada entrega é apresentada por quem a fez, não só pelo gestor.
- Feedback dos stakeholders (15–20 min). A parte mais importante e a mais pulada. Perguntas diretas: "isso resolve o que você precisava?", "o que mudaria?", "o que falta para você usar isso amanhã?".
- Próximos passos (5 min). O que o feedback muda no backlog: itens que sobem, itens que caem, ideias novas que entram para refinar.
O erro clássico é transformar a review em prestação de contas — uma leitura defensiva de "fizemos X, Y e Z" para provar que o time trabalhou. Review não é tribunal, é conversa sobre valor. Se os stakeholders saem sem ter opinado sobre nada, foi apresentação, não review. O passo a passo completo, com armadilhas e variações, está em como fazer uma sprint review.
O formato de uma boa retro
A retro é o bastidor. Um formato que funciona em 45–60 minutos, só com o time:
- Check-in (5 min). Uma pergunta leve para todo mundo falar ao menos uma vez — quem fala no início fala no meio.
- Coleta (10–15 min). Cada pessoa escreve em post-its o que percebeu na sprint. A dinâmica mais conhecida é o Start, Stop, Continue — começar, parar, continuar —, mas há dezenas de variações.
- Agrupamento e votação (10 min). Post-its parecidos se juntam; o time vota nos temas que mais importam. Discute-se o top 2 ou 3, não tudo.
- Discussão e ações (15–20 min). Para cada tema votado: o que está acontecendo, por quê, e uma ação concreta com dono e prazo.
- Fechamento (5 min). Revisão das ações combinadas e das ações da retro anterior — a parte que separa times que melhoram de times que só desabafam. Se as suas ações nunca saem do papel, vale ler como fazer as ações da retro virarem realidade.
Duas regras não negociáveis: sem stakeholders na sala e sem caça a culpados. A retro examina o sistema de trabalho, não as pessoas. Em times remotos ou híbridos, um board de post-its ao vivo resolve a logística — no TeamBOX, por exemplo, o time abre um canvas compartilhado de retro e cada pessoa escreve e vota em tempo real, com o histórico guardado para a retro seguinte comparar.
Exemplos: como as duas convivem em times de verdade
Time de marketing. A equipe da Renata roda campanhas em ciclos de duas semanas. Na review, ela convida o gerente comercial e a analista de produto: o time mostra as peças publicadas, os testes de anúncio que foram ao ar e o que está agendado — e o comercial pede ajuste no público de uma campanha, o que reordena o backlog. Na retro, dois dias depois e sem convidados, o time discute outra coisa: as aprovações de peça travaram três dias na diretoria, e a ação combinada é criar um lote único de aprovação às segundas. Repare: o assunto da retro (aprovação lenta) jamais apareceria com a diretoria na sala.
Time de RH. O time de recrutamento do Josué fecha ciclos mensais. Na review, os gestores requisitantes veem o funil: vagas fechadas, candidatos em etapa final, vagas em risco — e um gestor descobre que sua vaga empacou porque a descrição está genérica demais, e se compromete a reescrevê-la. Na retro, só o time: os testes técnicos estão demorando porque uma única pessoa corrige tudo. Ação: treinar mais dois avaliadores até o fim do mês.
Time de produto/engenharia. Na review, o time do Caio demonstra a funcionalidade nova para o suporte e para a gerente de operações — que aponta um caso de uso que ninguém tinha previsto e que vira item de backlog. Na retro, o time encara o incômodo real da sprint: o escopo mudou no meio do caminho duas vezes. A ação é um acordo com quem prioriza: mudança de escopo dentro da sprint só com troca explícita de itens.
Nos três casos, o padrão se repete: a review gera decisões sobre o que entregar; a retro gera decisões sobre como trabalhar. Misturá-las teria silenciado exatamente as conversas mais valiosas de cada uma.
Como encaixar as duas sem pesar a agenda
A objeção mais comum à separação é tempo: "duas reuniões de fechamento é demais". Três respostas práticas:
- Elas são mais curtas do que parecem. Para uma sprint de duas semanas, 45–60 minutos de review e 45–60 de retro são suficientes — juntas, uma fração pequena do tempo do ciclo. Separadas e bem conduzidas, costumam ser mais curtas que a "reunião única" inchada que tentam substituir.
- A ordem importa. Review primeiro, retro depois, ambas antes do próximo planejamento. O feedback da review alimenta a retro ("por que essa entrega decepcionou o cliente interno?") e as conclusões das duas alimentam o plano seguinte. Podem ser no mesmo dia, com um intervalo — o essencial é trocar a composição da sala.
- Adapte a cadência, não o propósito. Time com ciclos semanais pode fazer review toda semana e retro quinzenal, por exemplo. O que não funciona é fundir os propósitos. Para calibrar o conjunto inteiro de rituais sem sufocar o calendário do time, veja quantas cerimônias um time precisa.
Um atalho que ajuda gestores de qualquer área: nomeie as reuniões pelo que elas olham. "Revisão de entregas" e "conversa de processo" comunicam melhor que "review" e "retro" para times que não vêm do mundo ágil — e deixam óbvio por que os públicos são diferentes.
Erros comuns ao separar (ou não separar) as duas
- Fazer só a review. O time vira uma máquina de demonstrar que nunca melhora o próprio funcionamento. Os mesmos atritos se repetem sprint após sprint.
- Fazer só a retro. O time melhora o processo no vácuo, sem feedback de quem usa a entrega — e pode estar ficando ótimo em construir a coisa errada.
- Retro com chefe-convidado "só ouvindo". Não existe "só ouvindo": a presença de alguém de fora muda o que o time fala. Se a liderança quer visibilidade, o caminho é o time compartilhar as ações que saíram da retro, não a conversa crua.
- Review sem stakeholder. Time apresentando para si mesmo é ensaio, não review. Se ninguém de fora aparece, o problema a atacar é o convite (dia, horário, relevância), não a cerimônia.
- Nenhuma das duas gerar registro. Review sem ajuste de backlog e retro sem ação escrita são conversas que evaporam. Saia de cada uma com decisões anotadas — no TeamBOX, as ações da retro e os itens novos da review entram direto no board, o que evita o clássico "combinamos isso mesmo?".
- Culpar a cerimônia pelo problema de facilitação. Review monótona e retro silenciosa quase sempre são sintomas de condução, não do formato. Antes de cortar a reunião, invista em facilitação de cerimônias: timebox claro, participação distribuída e fechamento com decisões.
Se ficar com uma frase, que seja esta: review é a conversa do time com o mundo sobre o produto; retro é a conversa do time consigo mesmo sobre o processo. Times maduros protegem as duas — porque entregar a coisa certa e trabalhar do jeito certo são problemas diferentes, e cada um merece a própria sala.