Ultimamente tenho tido muito contato com Product Owners de áreas de negócios diferentes, de diversas empresas, que sempre trazem dúvidas de como cuidar do Backlog, como priorizar, se existem formas para trabalhar com esse artefato… A resposta é “sim” e todas elas podem ser aprendidas, assim como aprender mais sobre o produto e sobre o negócio que está envolvido também. Afinal de contas, a maior responsabilidade do Product Owner é levar conhecimento e experiência sobre o produto e tudo que permeia para o time, com objetivo de transmitir informações para que possam desenvolver, melhorar, inovar e incrementar cada vez mais as entregas.
Então vamos relembrar um pouco o papel e as responsabilidades do Product Owner… Sabemos que o PO deve ser acessível, bem informado e empoderado para tomar decisões. O PO deve saber o valor do negócio, a experiência do usuário em relação ao produto e a viabilidade técnica para produzir. Uma vez o PO tendo todas essas informações, ele poderá fazer a análise de viabilidade, a gestão do produto.
Além de tudo isso, o Product Owner é um profissional de relacionamento.
Portanto, se juntarmos todos esses fatores já temos várias dicas para se preocupar com “quem será nosso PO?”, antes mesmo do profissional assumir o seu papel com responsabilidade. O que eu quis dizer é que não adianta colocar uma pessoa que não conheça o negócio, ou que seja introspectiva ou que não saiba transmitir informações… Principalmente, que não tenha automia para tomadas de decisões necessárias com o time… Todos esses itens ajudam e muito ao Product Owner não conseguir fazer o trabalho com eficácia e ser julgado de forma errada. A responsabilidade de quem escolhe o PO é muito maior do que a de quem irá assumir esse papel. Cuidado!
Agora que já falamos sobre o perfil, papel e responsabilidade, vamos as sugestões para os Product Owners trabalharem com qualidade e eficácia:
Sugestão 1: O Product Backlog é um artefato do PO. Ele é responsável pelo o que entra, o que sai, o que é priorizado e qual o detalhe do conteúdo escrito. Pode ser compartilhado com o time e os envolvidos em alguns momentos, como por exemplo numa Release Planning ( leia sobre Release Planning clicando aqui!). Mas é o PO que mantem o product backlog ativo!
Sugestão 2: “Épico” é um pacote de funcionalidades que não conseguimos desenvolver e entregar em duas semanas de Sprint. Por isso quebramos essas funcionalidades (Features) em histórias (User Story) para conseguirmos ver as entregas por Sprint. Dessa forma não ficamos arrastando as mesmas histórias por meses nos Sprints, nos dando a falsa visão de que o trabalho não esta sendo bem feito ou não foi bem levantado e estimado. Demonstra que não foiprodutivo os Sprints!
Sugestão 3: Quando estiver escrevendo histórias para um determinado Sprint, fique atento no nível de dependência que elas têm entre si, ou na dependência que elas têm com outras histórias, que pertencem a outros Releases, descritas no Product Backlog e que não foram ainda priorizadas. Uma história pode não conseguir ser realizada e impactar a entrega, caso tenha dependência com outra.
Sugestão 4: A escrita das histórias precisa detalhar além do objetivo, regras de negócio, parametrizações, máscaras, informações que o Time de Desenvolvedores precisam ter para entregar a história. Além disso, é muito importante definir quais os Critérios de Aceite do PO para cada história. Isso vai dar um bom direcionamento na entrega.
Sugestão 5: Quando o PO tem histórias de produtos variados em seu Product Backlog, vale a pena criar uma coluna “produto”, para saber de qual produto essa entrega pertence. Pode ser feito o mesmo criando colunas para “impacto” e “release” que pertence.
Sugestão 6: O PO deve ouvir e negociar as histórias com as áreas impactadas e envolvidas para não ter retrabalho ou desperdicio com suas entregas. A comunicação deve fluir e não tem que ser impedimento para conseguir entregar o produto.
Sugestão 7: Há uma diferença entre Product Backlog e Sprint Backlog que na maioria das vezes os PO´s nem tem ciência disso. Leia o artigo que escrevi explicando a diferença e como trabalhar com eles, clicando aqui!
Sugestão 8: A técnica de “grooming” ou “refinamento” servem para tirar duvidas do PO e do Time de Desenvolvimento. É uma boa prática que quando bem feita, tende a diminuir absurdamente o tempo de Sprint Planning. Em vez de perder tempo, você ganha velocidade. Confira como fazer aqui!
Sugestão 9: Mantenha o Product Backlog sempre atualizado. Um PO organizado sempre tem pelo menos 1 Sprint a frente planejada, com histórias detalhas e refinadas para serem desenvolvidas. Histórias com nível de incerteza alto, não devem entrar para desenvolvimento, para não ter perda de produtividade do time. Por isso é necessário que o PO sempre refine bem as histórias.
Sugestão 10: Utilize o Definition of Ready (DoR), critérios que vão garantir a qualidade de ENTRADA do requisitos no Sprint e o Definition of Done (DoD), critérios que vão garantir a qualidade de SAÍDA do Sprint (como explicado na figura abaixo). As definições vão trazer mais clareza e objetividade para as atividades dentro do Sprint.
Todas as sugestões que eu escrevi acima vão te ajudar a fazer um bom trabalho como Product Owner e caso você ainda precise de mais informações de como escrever e quebrar histórias, compartilho com você um material em PDF bem didático que vai te ajudar nesse trabalho. Acesse clicando aqui!
A última dica que dou é que PO (Product Owner), SM (Scrum Master) e Time fazem parte de uma celula de desenvolvimento, onde todos estão comprometidos a entregar produto com valor de negócio, sem distinção de área, que fulano é de TI e sicrano é de Negócio. Não existe mais essa divisão de áreas em empresas que trabalham com gestão 3.0. TODOS precisam entregar produtos e atingir resultados. Juntos ganhamos mais velocidade e qualidade de entrega por reunirmos conhecimentos e vivências diferentes. Vamos cuidar do nosso pensamento para melhorarmos nossas ações sempre!
Espero que tenham gostado! Até breve pessoal 🙂