“O Product Owner não escreve histórias de usuário e os critérios de aceite…”, Eduardo Castro criador da formação de P.O (www.formacaodepo.com.br)
A afirmação do Eduardo me impactou, e me fez refletir mais sobre o verdadeiro papel do Product Owner, então antes de me bater, por favor, continue lendo…
Como assim? É isso mesmo, o P.O não deveria escrever histórias de usuário e nem os critérios de aceite, simplesmente porque histórias de usuários são requisitos de software, e os critérios de aceite são “regras” que indexam requisitos de interface, requisitos de qualidade, requisitos de segurança entre outros requisitos não funcionais, inclusive se você já teve contato com o método PBB (Product Backlog Building) do grande Fábio Aguiar, vai observar que a proposta dele é construir um backlog de forma colaborativa, para que o resultado seja mais efetivo.
O verdadeiro Product Owner é um Intraempreendedor, ele deve atuar focado nos requisitos de negócio e das partes interessadas., ou seja, o P.O deve estabelecer a visão do produto alinhada a estratégia de sua empresa, entendendo as necessidades, problemas do negócio e das partes interessadas, para planejar um roadmap, priorizando as funcionalidades, organizando as suas entregas/releases, otimizando assim o valor do produto.
– Poxa! Eu escrevo histórias todos os dias, estou quase lançando um livro de fábulas… (kkkk), então não sou um P.O?
Na minha humilde opinião, sim você é um Product Owner! Afinal seu time te reconhece assim, certo?! Mas seu nível de maturidade provavelmente é baixo e talvez isso nem seja culpa sua… mas como eternos aprendizes, precisamos nos atualizar para evoluirmos, na Scrum.org tem um artigo bem interessante que fala sobre a evolução do P.O, e os seus 5 níveis de maturidade, talvez seja um bom começo… inclusive o Eduardo Castro está sempre promovendo esse artigo, justamente para diminuir a disfunção que temos hoje no mercado sobre esse papel tão importante…
Artigo sobre a evolução do P.O: https://lnkd.in/duY8JKD2
Mas se o Product Owner não deve escrever histórias de usuário, então quem deve escrevê-las?
Antes de responder essa questão, quero deixar claro que o fato de acreditar que o P.O não deve escrever as histórias de usuário, não significa que ele não continuará sendo o responsável pelo backlog, e muito menos que ele não deva participar do processo.
Quem deve escrever histórias de usuário e critérios de aceite são os desenvolvedores!
Infelizmente muitas pessoas quando fazem a leitura do scrum guide, tem o entendimento equivocado sobre o papel e quem são os developers dentro do Time Scrum, acredito que há uma carência de informação sobre esse tema, no linkedin quase todos os dias na minha timeline, aparece um post de alguém falando sobre o papel do Scrum Master e do Product Owner, mas raramente vejo escreverem sobre os developers.
Quando falamos de software, grande parte das pessoas que estão iniciando no framework Scrum, acabam associando o papel dos developers somente na figura de desenvolvedores de softwares (Full-stack developer, Backend developer, Front-end developer e etc..), e isso até faz sentido, porque muitos times que utilizam Scrum não são realmente multifuncionais, mas pagam muito caro por isso.
De acordo com o Scrum guide: “Os Scrum Teams são multifuncionais, o que significa que os membros possuem todas as habilidades necessárias para criar valor a cada Sprint. Eles também são auto gerenciáveis, o que significa que decidem internamente quem faz o quê, quando e como.”
Se o Product Owner e o Scrum Master tem papéis e funções bem definidas ou pelo menos deveriam ter, sobra para os developers serem multifuncionais, e isso induz muitas pessoas a pensarem que os desenvolvedores de software devem ser responsáveis pelo desenvolvimento do código, teste, deploy entre outras funções, mas lembre-se, o que o guia diz é que o time deve ser multifuncional e não as pessoas, entendeu a pegadinha?
Então na prática um Scrum Team poderia ter os seguintes integrantes, pensando em desenvolvimento de softwares:
Product Owner;
Scrum Master;
Business Analytics (Developer);
Front-end developer (Developer);
Backend-developer (Developer);
UX Designer (Developer);
QA (Developer);
Então qual seria a ideia?
A sugestão aqui seria um trabalho colaborativo, onde o Business Analyst escreveria as histórias e critérios de aceite alinhado ao Product Owner, a partir da priorização das features, os software developers e UX ajudariam no refinamento técnico e de UX, e o QA na criação/validação dos cenários de teste.
Faz sentido? Tem outra sugestão coloca nos comentários 🙂
#productowner #product #sejamaisagilista #scrum #software #qualidade