Sprint Review: Como Conduzir Uma (Agenda e Exemplos)

Uma sprint review é o momento em que a equipe mostra o que realmente construiu. Quando bem conduzida, é uma das horas mais valiosas de um sprint: uma conversa real entre as pessoas que construíram o produto e as pessoas que o usam ou financiam.

O Que É uma Sprint Review?

Uma sprint review é um evento formal do Scrum realizado ao final de cada sprint. A equipe inspeciona o incremento (tudo o que foi feito durante o sprint) e colabora com os stakeholders para adaptar o product backlog com base no que aprenderam.

O Scrum Guide (Schwaber e Sutherland, 2020) a define como uma "sessão de trabalho", não como um relatório de status ou uma demo de via única. Essa distinção importa. Os stakeholders não são uma plateia; são participantes que ajudam a equipe a decidir o que construir a seguir.

A sprint review tem um timebox máximo de quatro horas para um sprint de um mês. Sprints mais curtos têm reviews proporcionalmente mais curtas; a maioria das equipes com sprints de duas semanas mantém isso em uma ou duas horas.

Principais Fatos

• O Scrum Guide (2020) especifica um timebox de quatro horas para um sprint de um mês, reduzido proporcionalmente para sprints mais curtos.
• A sprint review é um dos cinco eventos do Scrum: sprint planning, daily scrum, sprint review, sprint retrospective e o próprio sprint.
• Um relatório State of Agile de 2023 (Digital.ai) constatou que 71% dos entrevistados usavam Scrum ou um híbrido de Scrum, tornando a sprint review uma das reuniões estruturadas de feedback mais praticadas no software.

Um enquadramento útil: a sprint review responde "Construímos a coisa certa?" A sprint retrospective responde "Construímos da forma certa?"

Sprint Review vs Sprint Retrospective

Esses dois eventos acontecem em sequência ao final de cada sprint, então as equipes costumam misturá-los. Na verdade, são conversas fundamentalmente diferentes.

Para um detalhamento completo do formato e das perguntas da retrospectiva, veja o guia de sprint retrospective.

Quem Participa de uma Sprint Review?

O Scrum Guide lista os seguintes participantes:

• Time Scrum: os desenvolvedores que construíram o incremento, o Product Owner e o Scrum Master
• Stakeholders: qualquer pessoa que o Product Owner convide, como clientes, usuários, executivos ou patrocinadores do negócio
• Especialistas no assunto: opcionalmente, especialistas cujo input seja relevante para decisões sobre o que construir a seguir

O Product Owner geralmente convida os stakeholders. O Scrum Master garante que o evento permaneça produtivo e dentro do timebox. Os desenvolvedores apresentam o incremento e respondem às perguntas diretamente. Essa proximidade é intencional. Os stakeholders recebem informação sem filtro; os desenvolvedores recebem reações sem filtro.

Agenda da Sprint Review

Uma sprint review bem estruturada passa por cinco partes. Aqui está uma agenda de exemplo para uma review de 90 minutos (típica para um sprint de duas semanas):

Parte 1: Abertura (10 minutos)

O Product Owner abre retomando o sprint goal e listando os itens planejados para o sprint. Não pule isso. Stakeholders que não participaram do sprint planning precisam de contexto antes de ver a demo.

Parte 2: Demo do Incremento (40 minutos)

Os desenvolvedores demonstram o software funcionando. Software real, não slides. A demo deve mapear diretamente para o sprint goal e mostrar os critérios de aceitação sendo atendidos. Cada feature deve ser demonstrada em um cenário realista, não em um passo a passo higienizado.

Dica: atribua a cada desenvolvedor as features que ele construiu. Eles explicam o contexto e percorrem a funcionalidade. Isso é mais crível do que ter uma única pessoa demonstrando tudo.

Parte 3: Feedback dos Stakeholders (20 minutos)

Este é o núcleo da sprint review. O Product Owner facilita uma conversa aberta. Perguntas para provocar feedback útil:

• Isso resolve o problema que você tinha em mente?
• O que tornaria isso mais útil?
• No que devemos focar a seguir?
• Falta ou está errado alguma coisa?

Documente tudo. O input dos stakeholders molda diretamente a próxima atualização do backlog.

Parte 4: Revisão do Backlog (15 minutos)

O Product Owner percorre o product backlog atualizado. É aqui que o aprendizado do sprint se traduz em trabalho futuro. Novos itens surgem. Prioridades mudam. A equipe e os stakeholders se alinham sobre o que mais importa a seguir.

Parte 5: Encerramento (5 minutos)

Antecipe o próximo sprint goal, confirme a data da próxima review e agradeça aos stakeholders. Curto e claro.

Como Conduzir uma Sprint Review Eficaz

Passo 1: Prepare o ambiente de demo com antecedência

Não espere até a manhã da review. Configure um ambiente de staging, confirme que as contas de demo funcionam e teste quaisquer integrações ao vivo no dia anterior. Uma demo quebrada desperdiça o tempo de todos e corrói a confiança.

Passo 2: Alinhe os stakeholders antes da reunião

Envie um material curto de pré-leitura: o sprint goal, o que será demonstrado e qualquer contexto relevante (um fluxo de usuário que você está melhorando, um bug que você corrigiu). Os stakeholders dão feedback melhor quando entendem o ponto de partida.

Passo 3: Mantenha-se no software funcional

Mostre apenas o que está pronto segundo a Definition of Done. Se algo está 80% completo, não demonstre. Mostrar trabalho incompleto cria confusão e expectativas desalinhadas. O incremento é apenas o que atende ao padrão de "pronto" da equipe.

Passo 4: Convide os stakeholders certos

Mais nem sempre é melhor. Convide pessoas com poder de decisão ou insight direto de usuário. Um grupo focado de cinco pessoas engajadas gera feedback melhor do que uma plateia passiva de vinte.

Passo 5: Capture o feedback em tempo real

Designe uma pessoa para documentar o input dos stakeholders durante a discussão. Itens acionáveis vão direto para o backlog antes do fim da sessão, ou no mínimo são sinalizados para o Product Owner processar imediatamente depois.

Passo 6: Termine com um próximo passo claro

Antes que a sala se esvazie, declare o foco provável para o próximo sprint. Não precisa ser definitivo. Mas sair sem nenhuma direção compartilhada é uma oportunidade perdida. A sprint review deve parecer o fechamento de um capítulo e a abertura de outro.

Melhores Práticas para a Sprint Review

• Mantenha a demo realista. Use dados reais ou cenários próximos do real. Demos artificiais não revelam problemas reais de usabilidade.
• Dê timebox a cada segmento de demo. Se uma equipe tem cinco itens para mostrar, aloque tempo por item. Sem estrutura, as demos se estendem e o feedback fica espremido.
• Alterne quem apresenta. Cada desenvolvedor apresentando seu próprio trabalho constrói confiança na equipe e dá aos stakeholders uma visão mais clara do time.
• Não misture tópicos de retrospectiva. Questões de processo pertencem à retro. Se um stakeholder levantar uma preocupação de processo da equipe durante a review, anote e adie para a retro.
• Registre decisões-chave. O que os stakeholders aprovaram? O que perdeu prioridade? Quais novos pedidos surgiram? Essas decisões precisam de um registro documentado.

Erros Comuns

Tratar a review como uma demo de via única. Se os stakeholders estão apenas assistindo e aplaudindo, você está deixando valor na mesa. A sprint review é uma sessão colaborativa, não uma apresentação de teatro.

Demonstrar features que não estão prontas. Mostrar trabalho em andamento como se estivesse completo corrói a confiança. Se algo não está pronto, diga isso. Pule ou mostre brevemente com ressalvas claras.

Pular a discussão do backlog. Equipes que demonstram e dispensam perdem a parte mais importante: o que muda por causa do que acabaram de aprender. A discussão do backlog é onde o resultado do sprint se transforma no input do próximo sprint.

Conduzir sem os stakeholders certos. Uma sprint review só com membros internos da equipe é apenas um sync de time. O valor vem de perspectivas externas e feedback real de usuário.

Falta de preparação. Demos improvisadas costumam falhar ou passar do tempo. Um checklist curto de preparação, revisado no dia anterior, evita a maioria dos desastres de sprint review.

Perguntas Frequentes

O que é uma sprint review?

Uma sprint review é um evento do Scrum realizado ao final de cada sprint, no qual a equipe demonstra o incremento concluído aos stakeholders e coleta feedback para atualizar o product backlog. É uma sessão de trabalho colaborativa, não uma apresentação formal ou relatório de status.

Quanto tempo deve durar uma sprint review?

O Scrum Guide recomenda um máximo de quatro horas para um sprint de um mês. Para sprints de duas semanas, a maioria das equipes conduz reviews de uma a duas horas. O timebox escala com a duração do sprint: sprints mais curtos, reviews mais curtas.

Qual é a diferença entre uma sprint review e uma sprint retrospective?

A sprint review foca no produto: a equipe mostra o que construiu e os stakeholders dão feedback. A sprint retrospective foca no processo da equipe: como trabalharam juntos e o que melhorar. Ambas acontecem ao final do sprint, mas servem a propósitos diferentes e têm participantes diferentes.

Quem conduz a sprint review?

O Product Owner geralmente facilita a sprint review, abre a sessão e conduz a discussão do backlog. O Scrum Master garante que o evento permaneça dentro do timebox e produtivo. Os desenvolvedores apresentam o incremento diretamente.

O que acontece se o sprint goal não foi atingido?

A equipe demonstra o que foi concluído. Itens incompletos não são apresentados como prontos. A lacuna entre o que foi planejado e o que foi entregue se torna um input tanto para a atualização do backlog quanto para a retrospectiva. A transparência aqui vale mais do que tentar maquiar os resultados.

---

A sprint review é um dos eventos do Scrum mais simples de conduzir e um dos mais fáceis de conduzir mal. Uma demo curta e bem preparada, com os stakeholders certos na sala, transforma cada sprint em um ciclo de feedback real. E é isso que mantém as equipes construindo o produto certo, não apenas construindo rápido.

Para os outros eventos do Scrum, comece pelas cerimônias ágeis e pelo daily standup.