Sprint review: como conduzir e modelo de roteiro
A sprint review é o momento em que quem paga, usa ou depende do produto vê o que foi construído e ajuda a decidir o que vem a seguir. Bem conduzida, ela evita que o time passe meses construindo a coisa errada. Mal conduzida, vira um teatro de slides em que o time apresenta, as partes interessadas acenam com a cabeça e ninguém muda nada no backlog.
O sintoma mais comum é a plateia silenciosa. O time mostra tudo o que fez, pergunta "alguma dúvida?" e encerra. O problema não é falta de interesse dos convidados: é que o evento foi desenhado como apresentação, e não como conversa.
O roteiro abaixo parte do que o Guia do Scrum pede e transforma isso em uma pauta com tempos, perguntas e registro de decisões.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é Sprint Review, segundo o Guia do Scrum
O Guia do Scrum 2020 define a Sprint Review como o penúltimo evento da Sprint, cujo propósito é inspecionar o resultado da Sprint e determinar adaptações futuras. Os pontos principais:
- O Scrum Team apresenta o resultado do trabalho às principais partes interessadas, e o avanço em direção à Meta do Produto é discutido.
- Todos revisam o que foi feito e o que mudou no ambiente. Com base nisso, os participantes colaboram sobre o que fazer em seguida.
- O Product Backlog pode ser ajustado para aproveitar novas oportunidades.
- É uma sessão de trabalho. O Guia diz que o Scrum Team deve evitar limitá-la a uma apresentação.
- Timebox de no máximo quatro horas para uma Sprint de um mês. Em Sprints mais curtas, o evento costuma ser mais curto.
Um detalhe que muitos times ignoram: o Guia diz que a Sprint Review nunca deve ser considerada um portão para liberar valor. Um Incremento pode ser entregue às partes interessadas antes do fim da Sprint. A Review existe para aprender e ajustar a direção, não para carimbar a entrega.
Como a Review se encadeia com os outros eventos está em eventos do Scrum, e o panorama do framework, no guia completo de métodos ágeis e Scrum.
Sprint Review não é homologação nem reunião de status
Três confusões comuns, lado a lado:
| Critério | Sprint Review | Homologação | Reunião de status |
|---|---|---|---|
| Objetivo | Inspecionar o resultado e adaptar o rumo do produto | Aceitar formalmente uma entrega | Informar andamento a gestores |
| Quem fala mais | Partes interessadas e Scrum Team em conversa | Quem homologa | Quem apresenta |
| O que se mostra | O Incremento funcionando | Testes contra requisitos | Percentuais, prazos e riscos |
| O que sai | Product Backlog ajustado e próximos passos | Aceite ou lista de defeitos | Informação registrada |
Se a sua Review se parece com a terceira coluna, o público vai tratá-la como reunião dispensável. Se se parece com a segunda, o time vai trabalhar para "passar na prova" em vez de buscar retorno.
Quem convidar para a sprint review
- Scrum Team inteiro: Product Owner, Scrum Master e Developers. Os Developers mostram o que construíram e ouvem o retorno diretamente.
- Usuários reais ou seus representantes: quem vai usar o que foi construído no dia a dia.
- Patrocinador e áreas afetadas: quem decide investimento e quem precisa se preparar para a mudança (atendimento, treinamento, jurídico).
- Outros times com dependências: quando a entrega afeta ou depende do trabalho deles.
A lista é do Product Owner, que conhece as partes interessadas, mas qualquer pessoa do time pode sugerir nomes. Prefira poucos convidados que realmente usam ou decidem a um auditório cheio de observadores.
Como preparar a sprint review
Na véspera ou no último dia da Sprint, com um esforço pequeno:
- Confirme o que está pronto. Só entra na demonstração o que atende à Definição de Pronto. Trabalho inacabado pode ser mencionado, mas não demonstrado como se estivesse concluído.
- Releia a Meta da Sprint. A Review começa por ela: foi alcançada ou não? A meta da sprint é o fio condutor da conversa.
- Prepare um cenário real. Dados de teste parecidos com os de produção e um caso de uso que os convidados reconheçam.
- Defina quem mostra o quê. Os Developers que construíram mostram; o Product Owner contextualiza.
- Leve perguntas. Escolha duas ou três decisões em que o retorno dos convidados pode mudar o backlog.
- Tenha o Product Backlog à mão. Os próximos itens precisam estar visíveis para serem discutidos e reordenados na sessão.
Modelo de roteiro de sprint review (Sprint de duas semanas)
Os tempos são uma sugestão para uma Review de cerca de uma hora. Ajuste ao tamanho da Sprint e ao número de convidados, respeitando o timebox.
| Tempo | Bloco | Quem conduz | O que acontece |
|---|---|---|---|
| 0 a 5 min | Abertura | Product Owner | Meta do Produto, Meta da Sprint e se ela foi alcançada |
| 5 a 25 min | Incremento em uso | Developers | Demonstração do que está pronto, com cenário real; convidados podem testar |
| 25 a 35 min | Retorno | Scrum Master facilita | Perguntas preparadas e comentários livres; tudo anotado |
| 35 a 45 min | O que mudou no ambiente | Product Owner e convidados | Mercado, prazos, orçamento, regulação, prioridades da empresa |
| 45 a 55 min | Próximos passos | Product Owner | Itens do Product Backlog revistos, reordenados ou criados; previsão, se houver |
| 55 a 60 min | Fechamento | Scrum Master | Leitura das decisões e de quem faz o quê |
Perguntas que geram retorno de verdade
- "Isso resolve o problema de vocês como está, ou falta algo para usar amanhã?"
- "O que vocês fariam primeiro com essa funcionalidade? O que fariam se ela não existisse?"
- "Entre estes três próximos itens, qual faz mais falta e por quê?"
- "Mudou alguma coisa na área de vocês desde a última Review que devíamos saber?"
Perguntas abertas e específicas funcionam melhor do que "gostaram?".
Exemplo ilustrativo de sprint review
Uma secretaria estadual está implantando um sistema de gestão de frota de veículos oficiais, em Sprints de duas semanas. O exemplo é ilustrativo.
Meta da Sprint: o motorista registra a saída e a volta do veículo pelo celular, com quilometragem e foto do painel.
Convidados: dois motoristas, o chefe do setor de transporte e a responsável pelo controle de combustível.
O que aconteceu: os Developers mostraram o registro de saída e volta funcionando num celular comum. Os motoristas testaram durante a sessão e apontaram que a foto do painel falha em garagens escuras. A responsável pelo combustível perguntou se o abastecimento poderia ser registrado no mesmo fluxo, o que hoje é feito em papel. O chefe do setor contou que um novo decreto vai exigir relatório mensal de uso por veículo.
Decisões: o Product Owner criou um item para a captura da foto com pouca luz e o colocou no topo; o registro de abastecimento entrou no backlog para refinamento; o relatório mensal subiu de posição por causa do prazo do decreto. A meta foi alcançada, e o retorno mudou a ordem dos próximos três itens.
Como registrar e comunicar o que saiu da Review
Uma Review sem registro perde metade do valor. Anote, no mesmo dia:
- se a Meta da Sprint foi alcançada;
- os retornos recebidos e de quem vieram;
- as mudanças no Product Backlog (itens criados, removidos ou reordenados);
- as ações com responsável e prazo, como "confirmar com o jurídico o texto do decreto".
Para as partes interessadas que não puderam participar, um resumo curto com o estado do produto e as decisões tomadas evita que a mesma conversa se repita em reuniões paralelas. O status report gratuito da Projeto Diário ajuda a montar esse resumo com semáforo, avanços, riscos e decisões pendentes. Em projetos que também usam quadros Kanban para dar transparência às partes interessadas, o artigo sobre visibilidade com Kanban mostra como manter essa informação acessível entre uma Review e outra.
Erros comuns na sprint review
- Apresentação de slides em vez de produto funcionando. Ninguém dá retorno útil sobre um print de tela.
- Mostrar trabalho inacabado como pronto. Gera expectativa falsa e cobrança na Sprint seguinte.
- Só o Product Owner fala. Os Developers perdem o contato com quem usa o produto.
- Convidados errados. Gestores que não usam o sistema no lugar dos usuários que usam.
- Nada muda no backlog. Se a Review nunca altera a ordem dos itens, ela está servindo de reunião de status.
- Usar a Review como aceite formal. Segura entregas que poderiam ir para produção antes.
O que fazer agora
Na próxima Sprint, copie o roteiro acima, escolha três perguntas para os convidados e combine quem registra as decisões. Ao final, confira se pelo menos um item do Product Backlog mudou de posição por causa do que foi ouvido; se nenhum mudou, revise a lista de convidados e as perguntas. Para registrar participantes, decisões e ações com responsável e prazo, use a ata de reunião gratuita da Projeto Diário, que acompanha as ações até o fim e gera a ata pronta em Word.
