A Sprint Review é uma das cerimônias Ágeis mais importantes com certeza. Normalmente, é uma reunião ao vivo perto ou no final de uma sprint ou em todos as outras sprints.

Desenvolvedores, membros da equipe de produto e partes interessadas se reúnem para ver o que foi construído desde a última revisão. Seguindo o objetivo ágil de software funcionando, a equipe deve ser capaz de mostrar novos recursos e funcionalidades.

Esta parte da revisão pode ser chamada também de Sprint Demo.

🎯 Objetivo de uma Sprint Review

Curiosamente, o objetivo fundamental e o resultado da Sprint Review são frequentemente omitidos ou ignorados, ou desconhecidos pelas equipes. O objetivo da Sprint Review é coletar feedback sobre o Incremento do Produto das partes interessadas, considerar as condições atuais de negócios (como o uso do produto, concorrentes, vendas, marketing etc.) e planejar o que fazer a seguir.

As partes interessadas, tanto internas quanto, em alguns casos, externas, devem ser convidadas para a Sprint Review.

Em algumas empresas, clientes e usuários são convidados para as Sprint Reviews – se possível, dependendo de contratos e outros fatores.

Ainda observo em algumas organizações que os Times Scrum mostram apenas uma demonstração e código para si mesmos.

Não há interessados ​​convidados. Em vez disso, os desenvolvedores mostram o código e os testes para o Product Owner.

Nesse caso, não há inspeção e adaptação verdadeiras. O Product Owner não deve se surpreender com o Incremento.

Ao contrário, todo o Time Scrum deve buscar feedback dos outros.

🔍 Demonstrar não é tudo

Mas a demonstração é apenas uma parte da revisão da sprint. Além disso, a equipe deve revisar os objetivos do produto e como o trabalho concluído se alinha com os objetivos gerais do projeto.

A equipe deve determinar se o trabalho feito na sprint anterior ajudou a atingir as metas ou ficou aquém – talvez a equipe tenha trabalhado em algo ótimo, mas não progrediu em direção à meta.

Este é o momento em que a equipe pode corrigir o curso; talvez, ele escolha histórias diferentes para a próximo sprint, ou mude o foco, ou, se necessário, procure alterar os recursos da equipe para que diferentes histórias possam ser realizadas em sprints futuras ou para impactar a velocidade da equipe.

A revisão da sprint também ajuda as partes interessadas a entender melhor o status do produto e permite que elas usem e vejam o produto, talvez pela primeira vez.

Isso pode levar a discussões produtivas sobre o produto, incluindo se ele está pronto para os clientes, o que ainda precisa ser construído, o plano de lançamento e a composição de sprints futuros.

Até este ponto, esta reunião poderia ser realizada com um número limitado de pessoas – nem todo desenvolvedor precisa apresentar e nem todo stakeholder precisa revisar.

No entanto, a revisão da sprint ganha valor quando mais pessoas participam – e participam. Isso porque, além de demonstrações e revisões de metas, essa é uma atividade onde são feitas conversas e conexões importantes.

Vejamos alguns desses outros benefícios potenciais da revisão da sprint.

🗣️ Feedback para a equipe de desenvolvimento

No gerenciamento de projetos tradicional, a equipe do produto é responsável por escrever as especificações, entregá-las aos desenvolvedores e esperar que a equipe construa o que foi solicitado.

Durante o intervalo, os desenvolvedores geralmente não colaboram muito com a equipe do produto, esperando até que estejam “concluídos” para reunir todos novamente.

Este processo sempre causou frustração. Mesmo a melhor equipe terá dificuldade para entregar exatamente a coisa certa para o produto. Isso pode ser porque as necessidades mudaram, ou novas informações do cliente foram aprendidas, ou pode ser que os detalhes estivessem faltando na especificação original, e a equipe construiu o que achava certo (às vezes conhecido como critério do desenvolvedor) e acabou errado.

O Agile contorna isso com o ciclo do-inspecionar-adaptar que é incorporado ao processo.

Em vez de esperar até que tudo esteja completo, o Agile coloca pontos de verificação ao longo do caminho, onde o que foi “feito” pode ser “inspecionado” e quaisquer mudanças de direção ou alterações no produto podem ser discutidas com a equipe e outras partes interessadas, se necessário.

Ao adicionar esse ciclo de feedback ao processo, a equipe está constantemente ajustando o que está trabalhando e o que está priorizando e mudando de direção antes que seja tarde demais.

Fazer com que as partes interessadas forneçam feedback à equipe de desenvolvimento durante a revisão da sprint é uma ótima maneira de criar um produto melhor e manter o projeto na direção certa.

📢 Feedback da equipe de desenvolvimento

O feedback é melhor quando é multidirecional. Não deve ser limitado apenas aos stakeholders dando seus comentários aos desenvolvedores, bons e ruins, e a partir disso desenvolvedores e fazem mudanças.

Este também deve ser um momento para a equipe de desenvolvimento dar feedback às partes interessadas do projeto, incluindo a equipe do produto, a equipe de design ou qualquer outra pessoa que trabalhe com os desenvolvedores.

Pode ser que os requisitos não tenham ficado claros recentemente e a equipe os queira em um formato diferente.

Ou talvez haja uma maneira melhor de fazer o que a equipe de produto solicitou, e a equipe de desenvolvimento quer falar sobre como fazer as coisas de maneira diferente.

Portanto, além de dar feedback aos desenvolvedores, os desenvolvedores devem ter o poder de dar feedback ao produto.

Mais do que apenas dar comentários sobre como o projeto está operando, os desenvolvedores também devem usar parte desse tempo para entender melhor o produto e como seu trabalho está impactando o quadro geral.

Quando a equipe entende o raciocínio por trás do trabalho, eles tendem a ser mais bem-sucedidos em construí-lo.

A equipe também deve se sentir à vontade para dar feedback sobre o produto em si. Isso pode ser novas ideias para recursos, alterações em outros adicionais ou maneiras de atender a um novo cliente ou um novo caso de uso.

Se a equipe de desenvolvimento estiver trabalhando em estreita colaboração com o produto, provavelmente terá insights e pontos de vista que outras partes interessadas não têm.

Extrair isso da equipe durante a revisão da sprint pode ser uma ótima maneira de discutir novas ideias e ajudar a colaborar em um produto melhor.

🤝 Construção de relacionamento

A revisão da sprint geralmente é um evento positivo. Novas partes do produto podem ser reveladas pela primeira vez, metas foram adiantadas ou até mesmo concluídas, e pode haver conquistas a serem anunciadas e comemoradas.

Pela natureza alegre do evento, também é um bom momento para a construção de relacionamento com os stakeholders.

Embora alguns membros do desenvolvimento possam trabalhar em estreita colaboração com algumas partes interessadas, é raro que toda a equipe trabalhe em conjunto.

Fazer com que a equipe colabore durante a revisão da sprint é uma maneira natural de todas as partes interessadas colaborarem e trabalharem juntas de maneiras que podem não ter a chance de outra maneira.

O Agile valoriza muito os relacionamentos. No manifesto original, dois dos itens valorizam as pessoas sobre o processo e a colaboração do cliente.

Usar a revisão da sprint para ter toda a equipe, stakeholders e clientes, cria o ambiente para relacionamentos melhores e fortes entre todos.

Em geral, quanto melhores forem os relacionamentos entre a equipe de desenvolvimento e as partes interessadas, melhores serão os resultados.

Os desenvolvedores terão uma melhor compreensão das necessidades dos clientes, e a equipe de produto terá uma melhor avaliação de como trabalhar melhor com a equipe.

Todos são responsáveis ​​por construir valor, e quanto mais as pessoas colaborarem e apreciarem umas às outras, melhores serão os resultados.

🎁 O take-away

A reunião de revisão da sprint é uma parte importante do processo Agile. Uma parte da revisão inclui uma demonstração do trabalho concluído recentemente, permitindo que as partes interessadas vejam o software em funcionamento pela primeira vez.

O restante da revisão se concentra nas metas, como o produto está indo, como o trabalho está ajudando a atingir as metas e algumas discussões sobre lançamentos futuros.

Além disso, a revisão da sprint tem três funções mais importantes:

• Fornecer feedback para a equipe de desenvolvimento das partes interessadas;
• Fornecer feedback para as partes interessadas da equipe de desenvolvimento;
• Ajudar a construir e fortalecer o relacionamento entre todos os membros da equipe.

Pode ser tentador focar na parte de demonstração da revisão da sprint, mas isso é apenas metade da história. Ao ter uma visão mais ampla do produto, mais partes interessadas podem se envolver e participar, o que levará a uma equipe mais forte e a um produto melhor.

👥 Como envolver as partes interessadas em suas revisões de Sprint

Essa ausência de stakeholders pode ser consequência do progresso do produto, pois uma colaboração transparente entre a equipe e os stakeholders é fundamental para a construção de um produto de sucesso.

Como você pode evitar avaliações de Sprint ruins? Como coletamos feedback das partes interessadas? Como tornamos este evento Scrum valioso e significativo?

Aqui estão cinco razões pelas quais seus stakeholders não estão participando de revisões de sprint com soluções.

1. Você pode ter agendado a Revisão da Sprint na hora errada🕛

MOTIVO: O agendamento apático é uma das principais razões para a ausência de stakeholders nas revisões de sprint. As partes interessadas podem ter outros compromissos essenciais no dia da revisão da sprint.

Portanto, mesmo que estejam fisicamente disponíveis em sua agenda, sua mente pode estar absorta em outro trabalho importante.

RECURSO: Comunicação eficaz entre a equipe e as partes interessadas durante o agendamento.

Se possível, o cronograma da revisão do sprint deve ser definido no meio da semana em vez do último dia da semana. Na minha experiência, as Sprint Reviews de sexta-feira tiveram quase 50% das partes interessadas não aparecendo.

• Pense nos resultados e no propósito do evento.
• Tenha um cenário! Achei muito útil criar uma estratégia curta com o que deve ser discutido e quais perguntas vamos fazer aos nossos stakeholders.
• Deixe algum espaço para perguntas, preocupações e novas ideias das partes interessadas.
• Esteja preparado para uma discussão, não apenas uma apresentação.
• Esteja preparado com algumas técnicas de facilitação relevantes para este evento. (tenha cuidado, nem todos os métodos de facilitação são apropriados para a Revisão da Sprint).
• Pense no número de pessoas. Quantas equipes estarão presentes? Quantos interessados ​​virão? Escolha as técnicas que são relevantes para sua situação.

2. Sua Sprint Review é apenas uma demonstração🔎

MOTIVO: Outro motivo pelo qual um stakeholder pode pular a revisão do sprint pode ser por que você não consegue captar o interesse dele. A equipe às vezes exagera e converte a Sprint Review como uma demonstração.

Portanto, quando é apresentado apenas como uma demonstração e todos os outros interessados ​​estão apenas ouvindo, muitas vezes é sequestrado por uma discussão profunda unilateral que pode não interessar a todos os interessados.

RECURSO: O ônus está no Scrum Master para facilitar um fluxo suave de comunicação que mantém todas as partes interessadas envolvidas. A revisão pode ser mais imersiva onde as partes interessadas são solicitadas a se envolver melhor.

Pela minha experiência, costumo fazer uma pausa suave, cutucar todas as partes interessadas e convidá-las a abrir seus pensamentos. Algo muito interessante que pode ser feito é criar um acordo de trabalho.

• Acordo de trabalho – Uma prática poderosa que pode ajudá-lo a facilitar a Revisão da Sprint e outros eventos. Achei valioso reunir as partes interessadas e as equipes. Nós criamos nossos Acordos de Trabalho (para este evento e futuras revisões também). O resultado pode
  incluir as seguintes regras:

1. As partes interessadas fornecem feedback;
2. Todos podemos fazer perguntas;
3. Discussão e evidências em vez de brigas improdutivas;
4. Respeitar os time-boxes;
5. Compartilhar perspectivas de negócios;
6. Compartilhar perspectivas de tecnologia e viabilidade;
7. Pelo menos um representante do departamento X está presente nas Sprint Reviews.

Estes são apenas meus exemplos. Vocês podem criar juntos regras completamente diferentes que sejam relevantes para suas equipes, partes interessadas e situações.

3. Sua Sprint Review não está emocionante 🥲

Quantas vezes você já pensou: “Esta Sprint Review é inútil e chata!” ou “Estamos apenas revisando internamente o que já vimos antes como Time Scrum. Não temos feedback novo. Vamos pular este evento. Perda de tempo.”

MOTIVO: Às vezes, as partes interessadas não consideram a revisão do sprint necessária. Eles provavelmente não comparecerão, pois podem conhecer a discussão e as decisões tomadas durante o evento.

RECURSO: Antes do evento, as equipes Scrum devem encontrar maneiras de atrair ou puxar os interesses de seus stakeholders. É melhor estacionar o que provavelmente virá no próximo Sprint e incluir uma palavra na agenda da sua Revisão da Sprint.

Na minha experiência, isso também significaria uma participação mais ativa das partes interessadas, pois elas estarão ansiosas para ouvir o que está por vir.

• Utilize Gravação de um vídeo – além de anotar o que foi dito, considere a gravação de um vídeo, como facilitador, você não precisa ser essa pessoa que desenha ou escreve.
  Certifique-se apenas  de que alguma gravação foi feita. A gravação de um vídeo usando a funcionalidade cria uma excelente oportunidade de visualização diferente das notas. E pode abrir nossos cérebros para mais ideias e criatividade.
• Lean Coffee¹ – esta técnica pode estruturar sua discussão quando um grupo tem muitos comentários, ideias e perguntas.

4. Fluxo 🔃

MOTIVO: O fluxo da revisão também pode desinteressar a parte interessada. Discussões dispersas durante a revisão podem tornar a reunião tediosa. Às vezes, o ritmo inconsistente e as transições difíceis também podem dissuadir as partes interessadas.

RECURSO: O Scrum Master deve intervir e ajudar a equipe scrum a definir e manter um ritmo rápido do evento. Isso pode ser feito com um planejamento meticuloso antes da reunião, incentivando uma conversa tranquila e sem esforço entre a equipe e as partes interessadas.

• Perguntas abertas – comece com perguntas: o que, quando, por que, por que motivo, como. As perguntas fechadas são usadas apenas se você quiser confirmar algo ou terminar a atividade.
• 15% Solutions² – esta prática pode restringir muitos pontos de ação (também pode ser ótimo para
  outros eventos).

5. Feedback📣

MOTIVO: O objetivo principal da revisão da sprint é receber feedback das partes interessadas, mas muitas vezes, a parte interessada pode não ter a oportunidade de contribuir para a conversa, pois a equipe ingenuamente fica obcecada com sua apresentação.

RECURSO: A equipe pode planejar uma pausa para conversa após cada demonstração para que a parte interessada possa acompanhar o ritmo e os desenvolvimentos dos backlogs do produto.

Na minha experiência, após cada demonstração de recurso, há uma pequena pesquisa que acontece instantaneamente. Dessa forma, você pode realmente transformar uma demonstração em uma sessão de feedback colaborativo.

🗣️ Como Facilitar o Feedback

Crie um ambiente seguro que permita transparência. Estou ciente de que em algumas organizações, dependendo da cultura, inicialmente, alguns stakeholders chegam a Sprint Review com expectativas, energia e atitude diferentes. Achei útil configurar a cena antecipadamente nas primeiras Sprint Reviews. Pode incluir o objetivo do evento, a necessidade de perguntas e coleta de feedback, inspeção do mercado, oportunidades de negócios e tecnologia, etc.

Pense no que seria apropriado em seu contexto. Esta é uma sessão colaborativa. Certifique-se de que todos possam participar – ou fazer perguntas ou fornecer feedback.

Veja algumas dicas de técnicas abaixo:

• Incentive as pessoas a falar.
• Facilitar a visualização do feedback ajuda as pessoas a ver o que foi dito antes e cria um espaço para ideias criativas. Além disso, garante que todo o feedback seja coletado. Lembre-se, como facilitador, você pode pedir a alguém para ajudá-lo. Ser um facilitador não significa que todo o trabalho do escriba pertence a você.
• Observe a dinâmica. Se o engajamento diminuir, reaja e aja de acordo. Às vezes, tornar as coisas transparentes ajuda (O que aconteceu? Por que isso aconteceu?).
• Quando relevante, faça perguntas abertas (O que você acha? Por qual motivo você propõe isso? Que evidências você tem? O que os clientes dizem? Como eles usam o produto? O que poderia mudar o status quo? Qual é o resultado dos experimentos? Qual é o progresso em direção ao Objetivo do Produto?).
• Foco no valor. Não se esqueça do mais importante para a Sprint Review: discutir  valor e clientes.

Conclusão

Uma vez que percebemos o propósito da Sprint Review, fica mais fácil facilitar este evento. Nesta postagem do blog, forneci algumas dicas de facilitação e respostas com base na minha experiência e conhecimento.

Agora, depois de conhecer algumas dicas, é hora de colocá-las em prática! Tente repensar seu estilo atual e dê uma olhada nestes conselhos. Espero que você encontre algo que nunca praticou até agora e que incorpore em suas revisões da Sprint. Boa sorte!