Pular para o conteúdo
Aprovação ou Feedback?
Gestão de Pessoas

Aprovação ou Feedback?

#feedback#sprint#sprint review

Por Rafael Sabbagh

Publicado em Atualizado em 2 min de leituraK21

A reunião de Sprint Review começa. Time de Desenvolvimento e Product Owner apresentam para o cliente o que fizeram nesse Sprint. O cliente observa, mas pouco fala, exceto por algumas poucas perguntas básicas. Ao final, aprova (e até mesmo aplaude) e se despede.

Todos pensam: “ufa! A reunião foi um sucesso”. Mas será que foi mesmo? Na realidade, acredito que esse seja um dos piores cenários possíveis para uma Sprint Review. Pior que isso, talvez, só se o cliente não estiver presente.

Será que esse cliente entendeu o que lhe foi demonstrado? Será que ele realmente se importou com o que estava vendo? Ele certamente irá se importar no futuro, possivelmente quando utilizar o software e notar que não atende bem às suas necessidades.

O propósito da reunião de Sprint Review não é o de se obter a aprovação formal do cliente sobre o que foi feito no Sprint, ou seja, polegar para cima ou carimbo de “aceito” no contrato. Não é UAT (User Acceptance Testing) tampouco. O objetivo dessa reunião é de se obter feedback do cliente sobre o Incremento do Produto gerado no Sprint e, com isso, poder frequentemente fazer ajustes de direção e, assim, diminuir os riscos do projeto. É trabalho – e obrigação – do Time de Desenvolvimento e do Product Owner puxarem o feedback do cliente. Convidá-lo a usar o produto ali mesmo. Instigar. Fazer perguntas. Mostrar alternativas.

Aprovação ou Feedback?
Seu time busca aprovação ou feedback ao realizar uma demo para o cliente?

O cliente achou que algo não estava exatamente como ele queria? Ótimo! Deixemos a postura defensiva de lado. Não tenhamos medo. Nós não fizemos besteira. Não estragamos tudo. Na realidade, já esperávamos por isso. Faremos de tudo para acertar, claro, mas não sabemos ler a mente de ninguém. E, mesmo que soubéssemos, isso não adiantaria muito pois o cliente só irá saber exatamente o que ele precisa após ver algo pronto. O produto, na cabeça do cliente, é construído aos poucos, incrementalmente.

Mesmo quando der tudo errado e o cliente entender que tudo o que foi feito no Sprint não serve pra nada, pelo menos obteremos esse feedback antes de gastarmos meses trabalhando naquilo. Gestão de riscos pura, não?

Ou seja, o espírito da Sprint Review não é:

“Cliente, o que fizemos está aprovado?”

Mas talvez algo assim:

“Cliente, agora que você está tendo a oportunidade de ver funcionando (e experimentar!) esse Incremento do Produto que fizemos para você nesse Sprint, o que podemos modificar ou adicionar a ele para melhor atender às suas necessidades?”

Perguntas frequentes

Qual é o objetivo principal da reunião de Sprint Review no Scrum?

O objetivo principal da Sprint Review não é obter a aprovação formal do cliente ou realizar testes de aceitação. A reunião serve para colher feedback sobre o incremento do produto gerado na Sprint. Isso permite realizar ajustes de direção de forma frequente, diminuindo os riscos do projeto e garantindo um alinhamento constante com o cliente.

Como o time de desenvolvimento e o Product Owner devem atuar na Sprint Review?

O Time de Desenvolvimento e o Product Owner têm a obrigação de buscar ativamente o feedback do cliente durante a reunião. Em vez de apenas apresentar o trabalho, eles devem convidar o cliente a testar o produto na hora, fazendo perguntas, instigando a participação e demonstrando alternativas para colher percepções reais sobre o incremento.

Por que o cliente costuma pedir mudanças apenas depois de ver o produto pronto?

O cliente geralmente descobre suas reais necessidades apenas quando vê e experimenta o produto funcionando, pois a visão dele sobre a solução é construída de forma incremental. Pedidos de mudança durante a validação são esperados e não significam erro do time, mas sim uma oportunidade de ajustar o rumo antes de gastar meses de trabalho.

O que perguntar ao cliente na Sprint Review para obter bons feedbacks?

Em vez de perguntar se o trabalho está aprovado, a equipe deve questionar o cliente sobre o que pode ser modificado ou adicionado ao incremento demonstrado para atender melhor às suas necessidades. Essa postura foca na melhoria contínua do produto e na gestão de riscos, aproveitando a oportunidade de ver o software em funcionamento.

Pronto pra dar o próximo passo?

Conheça os cursos da K21 e leve essas ideias pra prática com quem vive agilidade todo dia.

Ver cursos K21

Continue lendo