O PO necessita ter conhecimento técnico?

Olá, Jackson, tudo bem?

O refinamento do backlog é um processo contínuo no qual o proprietário do produto e a equipe de desenvolvimento colaboram para garantir que os itens do Product Backlog sejam entendidos da mesma forma por todo o time e sejam ordenados de acordo com a sua prioridade em termos de valor comercial e esforço necessário.

Pode acontecer de o Product Owner ter conhecimento técnico e isso ajudará no processo de construção do produto, mas não é uma regra. O papel do PO é colher os itens de maior valor para o cliente naquele momento e transformar estes itens em histórias de usuário, dessa forma, durante a Planning, deve haver a explicação daquele item, seguido da criação das "tasks", ou tarefas, que são os passos técnicos que devem ser tomados para que aquela história de usuário seja executada com sucesso pelos programadores. As tarefas são criadas com ajuda dos programadores, que conhecem a parte técnica e podem dizer como gostariam de desenvolver determinada solução. Em seguida, são estimadas as tarefas e definidas quantas histórias do usuário são plausíveis de serem executadas na sprint.

No caso do seu exemplo, em um determinado ponto surgiu a necessidade de fazer a integração do sistema ou aplicativo que está sendo elaborado com o PIX. Nesse caso, o PO deve elaborar uma história do usuário com todas as funcionalidades que sejam importantes para que esta integração seja feita. Pode-se ainda existir no time um design UX, que poderá prototipar como ficaria a funcionalidade na tela do aplicativo ou sistema. Feito isso, o PO poderá conversar individualmente com o time de programação para entender qual a viabilidade de implementar esta nova funcionalidade no cenário atual do time Scrum, assim, colherá também quais os requisitos precisam ser trabalhados para que esta funcionalidade finalmente fique pronta. Esta parte de refinamento é feita durante toda a sprint, ou seja, o PO colhe informações com a equipe de negócios e o time de desenvolvimento constantemente, de modo que, quando chegar o momento da planning, consiga ter maior noção daquilo que é possível de ser realizado dentro do backlog. Assim, os desenvolvedores não precisarão debater durante todo o time-box da sprint, uma vez que já foi levantado anteriormente quais os pontos principais e possíveis de serem realizados.

Vale lembrar também que no desenvolvimento de programas existem diversas maneiras de se chegar a uma mesma solução, portanto, por mais que o PO tenha conhecimento técnico para dizer como deve ser feito determinado programa, pode ser que a equipe de desenvolvimento escolha fazer de outro modo, que seja mais conveniente para cada membro, desse modo, o PO não deve tirar a autonomia dos membros da equipe dizendo como deve ser feita determinada solução.

Espero ter ajudado, sinta-se à vontade para conversar sobre isso, caso seja do seu interesse.

Te desejo bons estudos! Abraços.

Certo, obrigado pela resposta. Entendi que o refinamento pode ser feito, em contato com a equipe, durante toda a sprint. Porém isso inevitavelmente tomará algum tempo de desenvolvimento. Aqui no curso foi mencionado que esse timebox, de refinamento com os desenvolvedores, não poderia ultrapassar 10% do total da sprint. Mas ainda me parece que se for algo realmente mais complexo, tende a estourar esse prazo. Esse ou o timebox do planning. Pode-se dizer que há casos em que isso é necessário? E também sobre esses 10% durante a sprint, eles devem ser estimados no planning?

Olá, Jackson!

Bem, partindo da ideia de que o refinamento seja feito antes da planning, desse modo, sim, tomará um pouco do tempo da pessoa desenvolvedora, contudo, continua sendo necessário para que na planning as histórias de usuário não sejam mirabolantes ou impossíveis de serem executadas. No curso se fala que o time-box para conversa entre os devs e PO é de 10% do tempo da sprint, mas isso não é uma obrigatoriedade, ou seja, pode acontecer do time dev junto ao PO precisarem de um pouco mais de tempo. Esse time-box é uma boa prática que ajuda na hora de perceber aonde o time está colocando mais esforços ao longo da sprint. Além disso, é importante ressaltar que também faz parte do trabalho da pessoa desenvolvedora pensar em como fará para executar as tarefas e cada pessoa toma o seu tempo para encontrar as melhores respostas sobre como irá executar tal projeto, para isso, o Scrum Guide não delimita tempo mínimo ou máximo, vai da expertise de cada um, e muitas vezes isso não acontece de maneira linear, em uma única conversa, e sim, ao longo da sprint e da experiência que o próprio time dev vai adquirindo ao executar o projeto. Nesse caso, a conversa entre PO e dev é uma constante ao longo da sprint, o que, por sua vez, acontece de maneira orgânica. O principal ponto nesse caso é que, ao chegar na planning, o PO já deve ter consultado seu time dev para ter uma noção sobre as complexidades das histórias de usuário e sobre a viabilidade de realização dela para o contexto atual.

Sobre a sua outra dúvida, no curso falamos desse time-box de 10% da sprint para conversa com o time dev, um tempo que por si só já está estimado, ou seja, corresponde aos 10% do tempo da sprint. Durante a planning, cada desenvolvedor deve estimar o tempo para realização de cada tarefa, para que ao final, sejam somados todos os story points daquela história e seja possível perceber quanto tempo será levado para a execução daquela história do usuário. Por exemplo, durante a planning o time dev estimou que levará cerca de 2 dias para realizar a tarefa de cadastro do usuário na plataforma; desse modo, esse tempo será somado ao tempo que as outras tarefas serão executadas para que, ao fim, seja possível visualizar quantas histórias do usuário podem ser executadas na próxima sprint. Este é o processo de estimar que se faz durante a planning. Você consegue perceber como funciona a dinâmica? Espero que sim!

Qualquer dúvida, sigo por aqui, bons estudos, Jackson!