Como realizar reuniões de revisão de Sprint eficazes no Scrum

Por que, às vezes, as revisões de sprint tendem a não ter "soco" suficiente

Às vezes, as pessoas ainda se referem à revisão do sprint como uma "demonstração" ou "vitrine" e isso está errado e muito distante do objetivo básico e da função da revisão. Talvez a principal razão pela qual alguns indivíduos ainda se referem a ele como uma demonstração é porque as histórias de usuários são demonstradas ao proprietário do produto para aprovação durante a reunião. Os três princípios básicos do scrum - transparência, inspeção e adaptação - devem ser pensados ​​para saber se satisfazem o evento de revisão. Demonstrar, apresentar ou fornecer informações não é o único objetivo do scrum. Além da inspeção, o processo de adaptação também deve ser iniciado. A adaptação é possível quando uma "demonstração" é fornecida e o feedback é solicitado ao público. O feedback ajuda a facilitar o recurso de autocorreção da metodologia scrum, após o qual a adaptação é possível. Em muitos casos, a equipe não entende adequadamente esse processo e a revisão é usada apenas para fins de apresentação. Em tais circunstâncias, o ciclo do processo scrum não é concluído e a revisão não funciona.

É possível realizar uma revisão significativa seguindo certas práticas benéficas.

Informe a equipe sobre a revisão

Permita que todos na equipe scrum, até mesmo os stakeholders, saibam exatamente quando e onde a revisão deve ser conduzida. Scrum suporta transparência e todos os eventos devem ser tornados públicos para que o processo de colaboração possa ser suportado. Os membros da equipe podem ser informados pessoalmente pelo proprietário do produto, pelo scrum master ou por qualquer outro membro da equipe. Se a equipe estiver desarticulada ou as partes interessadas não permanecerem fisicamente presentes no local do scrum, elas poderão ser informadas por meio de e-mails e chats online.

Exibindo histórias de usuários e trabalho de sprint

A equipe deve ser lembrada de se preparar para a reunião de revisão com bastante antecedência antes de seu início. As histórias de usuário desenvolvidas durante o sprint diário e o trabalho realizado devem ser apresentados ao proprietário do produto de maneira adequada e organizada. A equipe deve pensar em discutir as seguintes questões e se preparar para fornecer respostas para as mesmas:

Uma visão geral detalhada explicando o aspecto "o quê" e como o sprint prosseguiu
Exiba a funcionalidade de histórias do usuário e aceite-as como "Concluídas"
Uma explicação adequada sobre itens incompletos - por que eles não puderam ser desenvolvidos e transferi-los de volta para o backlog do produto
A equipe deve decidir como o trabalho deve ser demonstrado ao proprietário do produto. A equipe inteira pode apresentar o desenvolvimento como um todo, ou membros individuais podem se revezar na exibição de seu trabalho. Qualquer que seja o método, ele deve ser decidido.

Convidando os interessados

Embora não seja necessário que as partes interessadas visitem, elas devem, no entanto, ser convidadas a participar da reunião. Às vezes, questões básicas relacionadas aos critérios de aceitação podem ser identificadas e abordadas no nível básico com base no feedback obtido por eles. Isso pode ser muito benéfico para a equipe no desenvolvimento de histórias de usuários em sprints futuros.

Planejamento futuro

Este é um aspecto importante em relação à revisão e deve ser tratado com cuidado pelo scrum master. O principal papel do scrum master é garantir que o scrum seja implementado adequadamente no projeto em todos os momentos, mas um papel adicional também exige que a pessoa organize as reuniões do scrum de maneira frutífera para que possam ser eficazes. Os principais aspectos a serem considerados são:

Como deve ser calculado ou verificado o "sucesso" da revisão?
Como uma revisão bem-sucedida pode ser "alcançada"?
Qual deve ser o próximo passo a ser realizado após a revisão?
Como se pode verificar o que foi realmente alcançado durante o sprint?
O product owner deve se preparar também

O PO possui o projeto scrum em nome das partes interessadas e é o principal responsável pelo sucesso ou fracasso do projeto de várias maneiras. O PO prepara o backlog do produto e está bem familiarizado com os critérios de aceitação declarados nos itens do backlog do produto. A pessoa deve inspecionar como a equipe desenvolveu as histórias do usuário e fazer perguntas relacionadas à funcionalidade fornecida nas histórias. O PO tem uma visão clara sobre o objetivo do sprint e, portanto, deve verificar se o objetivo foi alcançado de maneira adequada ou não. Acima de tudo, o PO deve estudar os itens do backlog do sprint e preparar as perguntas relevantes com antecedência para obter o feedback adequado da equipe.

Observe o tempo!

Todo e qualquer evento no scrum é time box. É importante manter o tempo durante as revisões, mas, na prática, poucas áreas de scrum realmente têm relógios para controlar o tempo. Os membros da equipe usam dispositivos alternativos de contagem de tempo, como telefones celulares e agendas digitais, para que não seja dada importância suficiente a ter um relógio de parede ou algum dispositivo de contagem de tempo visível a todos o tempo todo. Cada membro da equipe deve seguir um relógio comum e agendar atividades com relação a ele.

Gravando os resultados da revisão

O objetivo básico de qualquer reunião é discutir e elaborar apelos à ação aceitáveis. Notas apropriadas devem ser mantidas durante a reunião para que os membros da equipe possam recapitular e revisar as atividades acionáveis ​​posteriormente, se necessário.