P.O. surpreso na Review? E agora?

Marcos Garrido, Sócio-fundador e Trainer na K21

Este post não tem tags.

Compartilhe:

Frequentemente nas minhas aulas, tenho ouvido a seguinte frase: “na reunião de Sprint Review, o Product Owner aceita ou rejeita o incremento de produto desenvolvido pelo time na Sprint”.

Sempre que ouço essa frase, paro tudo e começo uma boa conversa com os alunos para colocar as coisas no devido lugar.

Trabalhando como Product Owner desde 2008, acho muito estranho que essa frase ainda seja dita por aí como se o papel do time na reunião de Sprint Review fosse conseguir a Aprovação do Product Owner para os itens desenvolvidos. Esse pensamento ainda revela algumas outras disfunções que normalmente ficam ali escondidas no time.

Então vamos por partes:

  • Para começo de conversa, é preciso lembrar que, P.O. que se preza, senta junto com o time durante a Sprint. Então, se o P.O. está ali junto do time, por que cargas d’água a criatura resolve dar uma olhadinha no que o time produziu apenas na Sprint Review? Por que o P.O. não aproveita a proximidade com o time e colabora ao longo da Sprint para ver como as coisas estão ficando e aproveitar para ajudar o time a promover pequenos ajustes no rumo? Mas atenção: P.O. tá ali pra colaborar! Não para cobrar, exigir, mudar tudo, dar uma de chefe e ser cri-cri;
  • Outro ponto é a Definição de Pronto (Definition of Done). Definition of Done (DoD) é um acordo entre os membros do Time de Desenvolvimento e o Product Owner sobre o que Pronto significa. Se você tem uma DoD bem construída e que foi fruto de muita conversa entre todos, ela deveria bastar para que o Time de Desenvolvimento possa dizer que algo está pronto. Por que então o Product Owner teria que fazer um double check? Isso não faz o menor sentido! E tem mais: se a definition of Done não está boa o suficiente, que tal usar a Retrospectiva para inspeção e adaptação?
  • O último ponto é: na Sprint Review o Product Owner convida os stakeholders mais importantes/relevantes para que seja possível dar visibilidade sobre o andamento do trabalho e principalmente coletar seu feedback (veja no nosso post “Aprovação ou Feedback?”). Assim, que sentido tem esperar o cliente aparecer para na frente dele dizer que algo não está bom? Não teria sido muito melhor ajustar as coisas ao longo do desenvolvimento e mostrar ainda mais valor entregue na Review?

O fato é que Product Owner que só aparece na Sprint Review e ainda critica o trabalho do Time na frente do cliente acaba demonstrando que não fez a sua parte ao longo da Sprint.  Então, meu amigo P.O., se você quer saber se anda fazendo seu trabalho direitinho ou não, eu proponho um rápido teste: se você está numa Sprint Review e o que está sendo apresentado pelo Time é uma surpresa para você, bingo! Você é um Product Owner ausente e isso pode gerar uma série de disfunções que acabam por atrapalhar a vida de todo mundo.

E para fechar quero deixar bem claro: Product Owner é parte do Time sim. Product Owner de verdade senta junto, almoça junto, comemora e sofre junto com o Time e é claro, participa da Retrospectiva já que a melhoria contínua é para todo o Time de Scrum e não apenas para o Time de Desenvolvimento como muita gente ainda prega por aí. Mas opa! Isso é assunto para um próximo post! 🙂

Click here to read this post in english.

Marcos Garrido, Sócio-fundador e Trainer na K21

Sobre o autor(a)

Co-fundador, Consultor na Nower e Trainer na K21

Marcos Garrido, co-fundador da K21, é Certified Enterprise Coach (CEC), Certified Scrum Trainer (CST) e Certified Team Coach (CTC), fazendo parte do seleto grupo no mundo que possuem as três certificações mais importantes da Scrum Alliance. Com grande atuação internacional, possui larga experiência em Transformação Digital e Gestão de Produtos.

No headers found for the table of contents.

Artigos relacionados

Nas discussões e workshops sobre OKRs que fazemos nas empresas, um conceito sempre aparece: Estão faltando métricas de guard rail para equilibrar esses OKRs! As Métricas de saúde (ou Guard Rails) ajudam a liderança e as equipes a manterem um…

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

O que é gargalo Quando falamos sobre Kanban um dos nossos principais objetivos é identificar onde está o gargalo do nosso fluxo. O gargalo é a etapa em que os itens permanecem por mais tempo. É fundamental resolver os gargalos…

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

Seja em treinamentos, consultoria ou até mesmo com meus times de desenvolvimento. Uma coisa fácil de perceber é o desconforto causado quando comento sobre a necessidade de limitação de WIP. É algo que me causa estranheza. Por que as pessoas…

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

No artigo anterior, comentamos sobre o que era o Kanban, qual problema ele resolve e os princípios que norteiam esse método de gestão de trabalho. Este artigo é um complemento ao primeiro e nele quero tratar as práticas que o…