O que é Sprint Review?

A Sprint Review é definida no Scrum Guide, criado por Ken Schwaber e Jeff Sutherland. A edição de 2020 enfatiza inspeção do resultado, colaboração com stakeholders e adaptação futura. O Guia diferencia esse evento de um simples portão para liberar valor: Incrementos podem ser entregues antes da Review se estiverem prontos.

A Sprint Review encerra o trabalho da Sprint com inspeção do resultado e adaptação da direção do produto. O Scrum Team apresenta os resultados a stakeholders relevantes e conversa sobre progresso em direção ao Product Goal. O Scrum Guide de 2020 descreve uma sessão de trabalho, não uma apresentação protocolar. O Product Backlog pode ser ajustado para refletir oportunidades, riscos e informações recentes. O propósito não é apenas mostrar que pessoas estiveram ocupadas.

Traga o Incremento real. Mostre o que atende à Definition of Done e explique o que ficou fora. Um slide sobre percentuais de conclusão pode oferecer contexto, mas não substitui o produto ou serviço funcionando. Também não é preciso esperar uma cerimônia para liberar valor: o Guia permite entregar um Incremento antes do fim da Sprint. A Review inspeciona o resultado e o ambiente, independentemente da data de publicação.

Convide quem ajuda a decidir. Stakeholders relevantes podem incluir usuários, clientes, suporte, operação, negócio e outras áreas afetadas. Nem toda pessoa precisa estar em toda Review; escolha quem tem perspectiva útil para o objetivo e o produto. O Scrum Team inteiro participa. Quando apenas o Product Owner conversa com o público e depois retransmite tudo, Developers perdem a chance de ouvir perguntas e perceber nuances diretamente.

Dê contexto ao feedback. Comece pelo Sprint Goal e pelo que se pretendia aprender ou mudar. Mostre o comportamento do produto e deixe tempo para as pessoas explorarem, questionarem e compararem com sua experiência. Uma opinião isolada é sinal para investigação, não necessariamente ordem de implementação. Pergunte quem enfrenta o problema, com que frequência e qual impacto. Dados de uso e observações de clientes podem enriquecer a conversa, desde que se conheçam seus limites.

Olhe também para o mundo externo. Mudanças de mercado, regras, concorrência ou operação podem alterar prioridades entre uma Sprint e outra. A Review é oportunidade de conectar o Incremento ao contexto atual. O grupo pode descobrir que uma funcionalidade funciona tecnicamente, mas já não resolve o problema mais relevante. Adaptar o Product Backlog é mais valioso que insistir na lista original apenas para cumprir um plano antigo.

Não transforme feedback em aprovação binária. A Review não é um portão formal para decidir se trabalho atende à Definition of Done; essa qualidade deve ser verificada durante a Sprint. Stakeholders podem discordar do valor ou sugerir outra direção mesmo diante de um Incremento pronto. Separe conformidade técnica, aceitação de uma hipótese de produto e decisão de prioridade. Uma demonstração impecável pode revelar que o caminho precisa mudar.

Registre decisões e questões. Ao final, explicite o que foi aprendido, quais opções merecem investigação e quais itens do Product Backlog mudam. Nem toda ideia precisa virar item imediatamente. O Product Owner mantém responsabilidade por ordenar o backlog para maximizar valor, considerando o diálogo com o grupo. Um registro curto de decisão evita que a Review produza dezenas de pedidos sem clareza sobre importância ou próximo passo.

Proteja a natureza colaborativa. Uma agenda com dez apresentações consecutivas pode deixar dois minutos para perguntas. Planeje o tempo ao redor das decisões que precisam de feedback. Use demonstração, experimento, conversa com usuário ou análise de dados conforme o produto. Evite um público passivo que apenas aplaude. Quando não há Incremento pronto, seja transparente sobre o que ocorreu e use o encontro para aprender, sem fingir entrega.

Respeite o timebox. Para Sprint de um mês, a duração máxima é quatro horas; para Sprints menores, a Review costuma ser menor. O limite ajuda a concentrar a inspeção, não a reduzir toda conversa a uma apresentação acelerada. Perguntas profundas podem gerar trabalho posterior de descoberta. A Sprint Retrospective, que vem depois, examina como o time trabalhou; não substitui a inspeção do produto com stakeholders.

Feche o ciclo. O que se aprende na Review deve influenciar refinamento, priorização e a próxima Sprint Planning. Se stakeholders percebem que nenhum feedback altera decisões, deixam de participar. Se toda opinião vira prioridade automática, o Product Owner perde coerência estratégica. O valor do evento está em tornar evidências e escolhas transparentes, inclusive quando se decide não seguir uma sugestão.

Exemplo hipotético: um time melhora a consulta de faturas. O objetivo da Sprint era permitir que clientes encontrem documentos sem abrir chamado. Na Review, demonstra a busca funcionando, compartilha que os testes com pessoas encontraram confusão entre “fatura” e “recibo” e convida representantes de suporte e clientes para experimentar a tela. Não apresenta apenas uma lista de tarefas concluídas.

Uma cliente mostra que precisa filtrar pelo nome da filial, algo que o time não considerou. O grupo pergunta se essa necessidade é frequente e quais erros ocorrem sem o filtro. O Product Owner registra a oportunidade para investigar e reordena o Product Backlog considerando outros problemas conhecidos. Não promete implementar a ideia imediatamente só porque surgiu em público. Também informa um item selecionado que não ficou pronto e por que ele não integra o Incremento.

Na Planning seguinte, a equipe considera o aprendizado e pode escolher uma experiência menor para testar o filtro. O exemplo é hipotético; a lição é que a Review inspeciona produto e contexto para orientar a próxima decisão, e não apenas valida a cerimônia realizada.

A Sprint Review inspeciona resultado do produto e contexto com stakeholders para adaptar o Product Backlog. A Sprint Retrospective examina como o Scrum Team trabalhou e planeja melhorias de qualidade e efetividade. Ambas geram aprendizado, mas perguntas e participantes são diferentes. Usar uma no lugar da outra deixa uma dimensão sem inspeção.

Cursos K21 recomendados