TeamBOX
Cerimônias ágeis

Sprint review: como fazer uma review que engaja (não é retro!)

Sprint review é a cerimônia de demonstrar o que foi entregue e colher feedback de stakeholders. Veja a diferença para a retro e como preparar a demo.

6 min de leitura · Publicado em · Atualizado em

A sprint review é a cerimônia em que o time mostra o que foi entregue na sprint e colhe feedback de quem está de fora — clientes, outras áreas, liderança. O objetivo não é "apresentar por apresentar": é inspecionar o produto com as pessoas interessadas e deixar que esse feedback ajuste o rumo do backlog. No Scrum, ela acontece no fim de cada sprint, antes da retrospectiva.

E aqui vai o esclarecimento que dá nome a este guia: review não é retro. Times que fundem as duas cerimônias perdem as duas — e é por isso que a primeira seção é uma tabela.

Review × retrospectiva: a diferença de uma vez por todas

As duas acontecem no fim da sprint e as duas "olham para trás". A semelhança termina aí:

Sprint review Retrospectiva
Olha para O produto (o que foi construído) O processo (como o time trabalhou)
Participantes Time + stakeholders Só o time
Pergunta central "Isso resolve o problema? O que muda no rumo?" "Como foi trabalhar? O que vamos melhorar?"
Resultado Feedback que vira backlog Ações de melhoria com dono e prazo
Tom Aberto, de vitrine Protegido, de confiança

A ordem também importa: review antes, retro depois. O que acontece na review — a reação dos stakeholders, o feature que decepcionou, a demo que quebrou — frequentemente vira assunto da retrospectiva logo em seguida.

Misturar as duas cria um monstro: com stakeholders na sala, o time não fala a verdade sobre o processo (a retro morre); discutindo processo interno, os stakeholders se desligam (a review morre). Duas cerimônias, dois públicos, duas conversas.

Um teste rápido para saber se a sua "review" é mesmo uma review: conte quantas pessoas de fora do time estavam na última. Se a resposta for zero, o time fez um ensaio interno — útil, talvez, mas sem a matéria-prima que justifica a cerimônia: a reação de quem usa e de quem paga.

Como preparar uma demo que engaja

A review vive ou morre na demonstração. A diferença entre uma demo que prende a sala e uma que esvazia a agenda dos convidados na sprint seguinte está na preparação:

  1. Conte a partir do problema, não da tarefa. "Vocês lembram que o cliente precisava reemitir a nota sem abrir chamado? Olha como ficou" engaja; "fizemos os cards TB-231, TB-234 e TB-240" não. Stakeholder se importa com o problema dele, não com o seu quadro.
  2. Demonstre o fluxo de verdade, funcionando. Software real em ambiente estável, dados que fazem sentido, o caminho que o usuário faria. Slide com print é atalho para o desinteresse — e demo que quebra ao vivo, sem plano B, queima a credibilidade do time.
  3. Ensaie uma vez. Trinta minutos antes, alguém percorre o roteiro completo. É o suficiente para descobrir o ambiente fora do ar e o dado de teste apagado — antes da plateia.
  4. Distribua o palco. Quem construiu, demonstra. Review em que só o líder apresenta desperdiça a chance de o time ter contato direto com quem usa o que ele constrói — um dos maiores geradores de senso de propósito que existem.
  5. Mostre também o que não foi entregue. Item planejado que ficou de fora se anuncia com transparência e sem drama. Stakeholder maduro lida bem com replanejamento; ninguém lida bem com surpresa descoberta depois.

Como colher feedback de verdade (não aplausos)

Uma review sem perguntas da plateia falhou, por mais bonita que a demo tenha sido. Feedback é o produto da cerimônia — e ele precisa ser provocado:

  • Pare a cada bloco da demo e pergunte. Não deixe as perguntas para um "espaço aberto" nos últimos cinco minutos, quando metade já saiu. Perguntas específicas rendem mais que "o que acharam?": "Isso resolve o caso que você trouxe?", "O que ainda obrigaria o usuário a abrir chamado?", "Se isso for ao ar amanhã, o que quebra na sua área?"
  • Registre na frente de todos. Cada feedback anotado, com o nome de quem deu. Registrar em público sinaliza que a opinião tem consequência — e cria o compromisso de dar retorno.
  • Não prometa no calor da sala. "Ótima sugestão, vai para a triagem do backlog" é a resposta certa. Prioridade se decide no planejamento, com a visão do todo, não no impulso da review.
  • Acolha a crítica na frente da plateia. Se o time rebate cada ressalva, os stakeholders aprendem a elogiar e ir embora. O princípio é o mesmo da cultura de feedback: quem recebe mal, para de receber.

Do feedback ao backlog: fechando o ciclo

Feedback que não vira nada ensina os stakeholders a não voltar. Depois da review, o fluxo é curto:

  1. Triagem em até um ou dois dias. Cada item registrado recebe um destino: vira item de backlog (com o contexto de quem pediu), precisa de investigação, ou é descartado com uma resposta honesta a quem sugeriu.
  2. Rastro visível. O item de backlog nascido na review carrega a origem: "sugerido pela equipe de atendimento na review de 12/08". Isso muda a conversa da priorização — e mostra ao stakeholder que participar funciona.
  3. Feche o loop na review seguinte. "Sprint passada vocês pediram X; está aqui" é a frase que mais lota reviews. É a prova pública de que o feedback move o produto.

Esse ciclo — demo, feedback, backlog, demo de novo — é o que torna a review a cerimônia favorita dos stakeholders quando bem feita: é o único lugar onde eles veem, com os próprios olhos e em ritmo constante, o produto respondendo ao que dizem.

A review de sprint no TeamBOX

No TeamBOX, a review é um dos Cerimônias do time: o gestor cria o board da cerimônia para a equipe a partir do template pronto de Review de sprint — e pode ajustar ou partir do board Livre, com colunas personalizadas, se o formato da sua review for diferente (por exemplo: Demonstrado · Feedback recebido · Vai para o backlog). Há templates também para Retrospectiva clássica, Start-Stop-Continue, Kanban e Backlog.

Durante a cerimônia, todo o time edita o board junto, ao vivo, com presença em tempo real: enquanto um demonstra, os outros registram o feedback dos stakeholders nos cartões, na hora — nada se perde para a memória. Ao final, encerrar o ritual congela o board, que vira histórico da equipe: na review seguinte, é só abrir a anterior para fechar o loop do que foi pedido e entregue.

O time participa com o mesmo login do 1:1, pelo convite do liderado — cerimônias do time e conversas individuais no mesmo lugar. É grátis para começar.

Perguntas frequentes

O que é uma sprint review?

É a cerimônia no fim da sprint em que o time demonstra o que foi entregue e colhe feedback de stakeholders — clientes, outras áreas, liderança. O objetivo é inspecionar o produto e ajustar o rumo do que vem a seguir.

Qual a diferença entre sprint review e retrospectiva?

A review olha para o produto, com stakeholders na sala: o que foi entregue e o que o feedback muda no backlog. A retrospectiva olha para o processo, só com o time: como trabalhamos e o que vamos melhorar. São cerimônias distintas e as duas são necessárias.

Quem participa da sprint review?

O time inteiro e os stakeholders interessados no que foi construído: quem pediu, quem vai usar, quem depende da entrega. Review sem stakeholder é ensaio — o feedback externo é o motivo da cerimônia existir.

Como fazer uma boa demo na sprint review?

Demonstre a partir do problema do usuário, não da lista de tarefas: mostre o fluxo funcionando de verdade, em linguagem de negócio, e pare para perguntas. Prepare antes — demo improvisada em ambiente quebrado desperdiça a atenção de todos.

O que fazer com o feedback da review?

Registre cada feedback durante a própria cerimônia e depois triagem: o que vira item de backlog, o que precisa de investigação e o que é descartado (com resposta a quem sugeriu). Feedback que não deixa rastro ensina os stakeholders a não voltar.

Leia também

Coloque isso em prática no TeamBOX

No TeamBOX, gestor e liderado fazem a 1:1 no mesmo tabuleiro — pauta, feedbacks, PDI e histórico num só lugar.

Começar grátis →