A sprint do scrum começa com uma reunião de planejamento em que o PO transmite e prioriza os requisitos ou recursos do aplicativo para a equipe de desenvolvimento. O proprietário do produto ajuda a priorizar as histórias de usuário do backlog para que a equipe sabe que histórias para trabalhar durante a sprint. Nesse ponto, o PO é responsável por responder a quaisquer perguntas da equipe de desenvolvimento para ajudar a esclarecer quaisquer detalhes para que eles possam executar seu trabalho.

As responsabilidades do Product Owner

O trabalho do PO é quase que inteiramente composto por planejamento, comunicação e mais comunicação. O time precisa ter uma visão clara sobre o que fazer em cada sprint, os stakeholders precisam ter um canal aberto para feedback e entregas e todos devem seguir a mesma visão definida para o produto. Entenda as responsabilidades do PO:

Refinamento do Backlog: Com o input de Arquitetos, Engenheiros de software e outros stakeholders, o PO tem a responsabilidade de construir, aprimorar e manter o backlog do time. O backlog é geralmente constituído de novas funcionalidades, porém também contém erros (bugs) e melhorias. Ele é priorizado com base em seu valor para os usuários, tempo de desenvolvimento e outras dependências, que podem ser identificadas na reunião de planejamento de cada Sprint. Saiba mais sobre Backlogs aqui: O que é um Product Backlog?

Planejamento de Sprints: O PO revisa e reprioriza as estórias do backlog como parte do trabalho preparatório da reunião de planejamento de sprint. Isso pode incluir a coordenação e gerenciamento de dependências entre outros times (com outros Product Owners). Durante as reuniões de planejamento de sprints, o PO deve ser a maior fonte de informações sobre o detalhe das estórias e prioridades e tem a responsabilidade de aceitar o planejamento final feito pelo time.

Elaboração de estórias no dia-a-dia: A maioria dos itens do backlog são elaborados e quebrados em estórias para desenvolvimento. Isso pode acontecer antes da sprint, durante a reunião de planejamento ou durante a própria sprint. Qualquer membro do time pode escrever estórias e critérios de aceitação e o PO tem a responsabilidade de manter o processo fluido. Geralmente é bom ter o equivalente a duas sprints em estórias escritas, pois ajuda a manter o ritmo do time em caso de imprevistos. Saiba mais sobre user stories aqui: O que é uma user story?

Auxiliar no BDD (BDD — Behavior Driven Development (Desenvolvimento Guiado por Comportamento): O PO também pode participar no desenvolvimento dos critério de aceitação para estórias. O BDD é uma abordagem que visa focar no comportamento de uma determinada parte do sistema onde se espera atingir um objetivo e geralmente excede os limites da equipe de tecnologia, com uma linguagem de fácil interpretação. Para saber mais sobre o BBD, leia mais aqui.

Obs: anteriormente, eu havia de forma errônea mencionado o TDD como o ponto foco desse parágrafo, obrigado pelo toque Vladson! 🙂

Aceitando estórias: O PO é o único membro do time que pode aceitar estórias como concluídas.Isso inclui a validação de que a estória possui os critérios para aceitação e tem o testes de aceitação persistentes e apropriados. Fazendo isso, o PO realiza sua função de garantia de qualidade, focando primariamente em produtos prontos para usar.

Entendendo o trabalho de facilitador: Facilitadores são as pessoas que ajudam os implementadores a se concentrar na implementação. Eles se certificam que todos os implementadores estão aptos trabalhar e com o mesmo objetivo, removendo obstáculos do caminho. O PO é o facilitador do time e deve abraçar essa causa para que o time faça um trabalho bem feito.

Participar na retrospectiva e no demo: Como um membro integral do time e o responsável pelos requerimentos, o PO tem um importante papel na reunião de demonstração para revisar e aceitar estórias. Nessa reunião o PO também deve prover feedback para o time e coletar informações para os stakeholders.

O papel do Product Owner em projetos e programas

As iterações (ou sprints) e times servem um propósito maior: realizar entregas frequentes e confiáveis de soluções com valor agregado. Durante o curso de cada iteração, o Product Owner deve coordenar o planejamento com outros Product Owners. Isso é geralmente alcançado através de uma reunião semanal com outros POs para sincronizar as prioridades e dependências.

Nesse caso, o PO também deve ser responsável por criar e manter um roadmap de funcionalidades de alto valor futuras. Assim é possível coordenar as prioridades entre outros POs e stakeholders.

As diferenças entre Product Owner e um Product Manager

Em escala, é impossível que uma pessoa lide com a estratégia de produto e marketing e também se dedique a um time ágil. Por isso, já que o Product Manager e o Product Owner compartilham a autoridade sobre o conteúdo e estórias de cada projeto, é importante haver uma distinção clara dos papéis e responsabilidades de cada um, conforme ilustrado abaixo:

Considerações finais

O trabalho de PO pode ser extremamente cansativo, porém é igualmente satisfatório e enriquecedor. Você pode ter certeza de que vai aprender muito nessa função e a partir daí poderá voar longe. E não se esqueça: procedimentos e processos são ótimos, mas como o próprio manifesto agile diz:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

• Indivíduos e interação entre eles mais que processos e ferramentas.
• Software em funcionamento mais que documentação abrangente.
• Colaboração com o cliente mais que negociação de contratos.
• Responder a mudanças mais que seguir um plano

Na ACerT você pode realizar o curso e adquirir a certificação internacional SCRUM Product Owner Professional Certificate (SPOPC)  CertiProf e atuar num mercado promissor!