Aprovação ou Feedback?

Compartilhe:

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?”

Sobre o autor(a)

Co-fundador e Trainer na K21

Rafael Sabbagh é co-fundador da K21 e foi membro do Board de Diretores da Scrum Alliance entre 2015 e 2017. Ele é Certified Scrum Trainer (CST) pela Scrum Alliance e também Accredited Kanban Trainer (AKT) pela Kanban University. Atuando em nível executivo, possui uma vasta experiência em Transformação Digital e Gestão de Produtos. Ao longo da sua carreira, já treinou milhares de Scrum Masters, Product Owners e membros de equipes em mais de 15 países na Europa, América e Ásia.

No headers found for the table of contents.

Artigos relacionados

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Nos times ágeis, é comum nos depararmos com comportamentos que, mesmo não intencionais, acabam prejudicando a colaboração e os resultados. alguns deles foram agrupados no chamado Reino Animal das Disfunções na Agilidade. Cada disfunção é representada por um acrônimo em…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Na última segunda-feira, publiquei o artigo sobre critérios relevantes para avaliar e melhorar a saúde das histórias de usuário. Recebi bons feedbacks sobre o assunto. Entretanto surgiram dúvidas e algumas reclamações sobre a definição da Necessidade. No artigo, escrevi “A…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Quando falamos de Histórias de Usuário, estamos falando de um meio simples e prático para descrevermos as necessidades das pessoas que utilizam nosso produto / serviço. Em diversos treinamentos as pessoas perguntam qual a melhor forma de escrever uma história….

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Você é o Product Owner e está diante do seu product backlog, que precisa ser priorizado. No entanto, ainda não sabe por onde começar. A Técnica MoSCoW te ajuda a fazer isso de forma rápida. Vamos vê-lo. MoSCoW A classificação…