Como obter o máximo das revisões de sprint

Sentamos com o Scrum Master Henrique Ruocco para discutir as melhores práticas para a revisão de sprint. Desde que se juntou à Programmers em 2017, ele ajudou inúmeros clientes a alcançar seus objetivos de negócios e tem sido um defensor ativo dos processos Scrum. Descubra suas ideias sobre revisões de sprint, coleta do melhor feedback possível dos stakeholders e muito mais abaixo.

Qual é o objetivo da revisão de sprint?

Henrique Ruocco: Do meu ponto de vista, temos três objetivos para a revisão de sprint. O primeiro é inspecionar o incremento. A equipe geralmente apresenta o incremento concluído aos stakeholders, mostrando todos os itens finalizados.

O segundo é, na minha opinião, a parte mais importante de uma revisão de sprint: obter feedback. Precisamos coletar todo o feedback dos stakeholders, incluindo proprietários do produto (PO), clientes e outras partes interessadas. Devemos garantir que o produto esteja alinhado com suas expectativas e necessidades.

O objetivo final é adaptar e melhorar. Com base no feedback, o proprietário do produto pode fazer ajustes no backlog. Eles podem adicionar novos itens, histórias, prioridades ou detalhes para refinar as próximas sprints.

Qual deve ser a duração de uma revisão de sprint?

Henrique Ruocco: Isso depende da complexidade do trabalho e da quantidade de feedback que precisa ser discutido. No entanto, eu recomendaria que a revisão de sprint tenha no máximo quatro horas. Deve ser tempo suficiente para alcançar e discutir todos os objetivos e o feedback, mas não tão longa a ponto de se tornar improdutiva ou entediante.

Nessa reunião de 4 horas, quanto tempo deve ser gasto na demonstração, facilitando o feedback e outras atividades?

Henrique Ruocco: Isso depende da sua preferência pessoal. Para mim, começo com um período de apresentações. Acho importante cumprimentar a todos. Em seguida, explico rapidamente todos os tópicos que serão abordados durante a chamada. Portanto, eu diria que cinco minutos seriam suficientes para toda a introdução.

Em seguida, tento alocar a maior parte do tempo para a demonstração e o período de feedback. Começamos demonstrando o trabalho concluído. As equipes de desenvolvimento mostram as funcionalidades de todos os itens desenvolvidos durante a sprint que são considerados concluídos. A definição de pronto (DoD) é importante aqui. Ela demonstra que o item está realmente finalizado e pronto para ser implantado na produção.

Após todas as demonstrações, temos o período de feedback. Aqui, os stakeholders dizem à equipe de desenvolvimento se tudo está bom e se tudo faz sentido para seus objetivos comerciais. O período de feedback garante que todos estejam na mesma página.
Em seguida, podemos discutir se os objetivos da sprint foram alcançados. E, finalmente, podemos fazer uma revisão do backlog do produto. Com base no feedback que recebemos, podemos discutir algumas alterações e repriorizar as coisas. No entanto, esta é apenas uma discussão rápida, pois a maior parte da priorização do backlog do produto ocorrerá no planejamento da próxima sprint.

Quem você acha que deve participar de uma revisão de sprint, tanto da equipe de desenvolvimento quanto do cliente?

Henrique Ruocco: A revisão de sprint é um evento colaborativo, então incluiremos toda a equipe de desenvolvimento, incluindo os desenvolvedores, o Scrum Master e o proprietário do produto. E, o que é muito importante, precisamos dos principais stakeholders, que podem incluir clientes, usuários e gerentes. São todas as pessoas relacionadas ou interessadas no produto.

Precisamos que todas essas pessoas participem da chamada para nos fornecer informações valiosas. Esses feedbacks garantem que saibamos qual é nosso objetivo e que estamos em boa forma para a próxima sprint.

Qual é a maneira mais eficaz de maximizar a quantidade e a qualidade do feedback dos stakeholders durante a revisão da sprint?

Henrique Ruocco: Eu acredito que a maneira mais eficaz de facilitar o feedback dos stakeholders é criar um ambiente aberto e acolhedor. Esse ambiente encoraja os stakeholders a fazer perguntas, expressar suas preocupações sobre o produto e oferecer sugestões.

Claro, você também precisa manter a reunião focada na solicitação de feedback e fazer boas perguntas para obter feedback mais específico dos stakeholders. Ajuda a simular alguns cenários reais para ajudá-los a entender a funcionalidade do produto e garantir que todos estejam na mesma página.

Após a reunião, você pode tomar decisões com base no feedback que leve o produto na direção certa.

Como você garante que o feedback recebido na revisão da sprint seja usado na próxima sprint e no gerenciamento do backlog?

Henrique Ruocco: Normalmente, a equipe Scrum, especialmente o proprietário do produto, captura todo o feedback durante a reunião. Em seguida, eles devem categorizá-lo e priorizá-lo com base no valor comercial.

O valor comercial pode ser tudo o que o proprietário do produto considera mais importante para o cliente, incluindo o retorno sobre o investimento, tamanho da base de usuários e outros fatores. O feedback que se alinha com a visão do produto deve influenciar o próximo objetivo da sprint e o backlog do produto.

Se houver feedback que pareça estar fora de contexto, discutimos isso com os stakeholders durante ou após a revisão do sprint para entender por que ele surgiu. Por exemplo, se um stakeholder trouxer algo que não tem relação com o produto em si, vale a pena perguntar a eles, sempre que possível, o motivo pelo qual isso surgiu. Na minha opinião, às vezes o feedback pode não fazer sentido inicialmente, mas o stakeholder pode estar vendo algo que você não viu.

Quais são alguns dos erros comuns que as pessoas cometem na revisão de sprint?

Henrique Ruocco: Sim, infelizmente, eu definitivamente já vi erros. O maior é não se preparar adequadamente para a reunião. Às vezes, problemas surgem durante uma demonstração ao vivo, o que pode causar uma péssima impressão nos stakeholders em relação aos itens criados durante a sprint. Portanto, prepare-se adequadamente. Faça uma apresentação simulada antes para garantir que tudo ocorra sem problemas.

Outro erro comum é usar a revisão da sprint apenas como uma reunião de status. Em vez de se concentrar na coleta de feedback, essas equipes se concentram no progresso. Acompanhar o progresso é importante, mas esse não é o momento para isso. A revisão de sprint é um momento para demonstrar o trabalho e garantir que estamos no caminho certo.

As equipes Scrum frequentemente esquecem de convidar alguns stakeholders-chave por engano. Se estamos trabalhando para um usuário específico, podemos descobrir que eles não estão na revisão da sprint. Como podemos dizer que isso vai funcionar para eles?
Falando em stakeholders, é comum as equipes Scrum não envolvê-los. Elas não fazem perguntas a esses stakeholders ou não os incentivam a falar mais. Às vezes, você apenas demonstra seu trabalho, e todos ficam em silêncio. É preciso fazer perguntas para incentivá-los a participar mais ativamente.

Por fim, e provavelmente o erro mais comum: as pessoas podem falar sobre outras coisas na revisão, por exemplo, como fazer brigadeiro, sei lá. Ou talvez algo relacionado ao produto, mas que não está no tópico da revisão, como “Tenho uma pergunta sobre este item no backlog.” É preciso deixar claro que a revisão de sprint não é o momento para essas conversas.

Como você encoraja o usuário final a participar da revisão da sprint? Isso é um problema às vezes?

Henrique Ruocco: É importante envolvê-los. Pode ser difícil, mas lembre-os de que eles vão usar essas funcionalidades e que seria ótimo se pudessem participar dessa chamada para garantir que elas sejam úteis para eles.

Algumas outras práticas que você gostaria de compartilhar?

Henrique Ruocco: Mantenha o foco no objetivo do sprint durante a chamada. Não fale sobre brigadeiros [risos]. Você precisa entender com os stakeholders se atingiu o objetivo do sprint.

Tente envolver os stakeholders. É realmente um momento importante para fazer perguntas sobre o produto, seu futuro e o mercado. Isso ajudará no planejamento dos próximos sprints.

Por fim, certifique-se de comemorar! Se você definiu um objetivo para o sprint e conseguiu realizar tudo e recebeu um ótimo feedback, celebre. Isso realmente ajuda a equipe.

Programmers Agile Experience

Se você deseja trazer mais agilidade para o seu negócio, não deixe de acessar e descobrir o nosso modelo de engajamento, Programmers Agile Experience. Uma metodologia que indica caminhos de forma interativa e incremental, expondo ineficiência e engajado por completo todos os envolvidos. Evolui de acordo com o feedback e priorizações internas, permitindo que as organizações inovem com agilidade. Estamos aqui para ajudá-lo a alcançar o sucesso em um mundo cada vez mais dinâmico e digital.

Quer aplicar nossa metodologia no seu negócio? Entre em contato com um dos nossos especialista!