Product Owner (PO)

Responsabilidades

O Product Owner é o ponto central da liderança do produto. Ele é a única autoridade responsável por decidir quais recursos e funcionalidades construir e a ordem em que construí-los. O Product Owner mantém e comunica a todos os outros participantes uma visão clara do que a equipe Scrum está tentando alcançar. Como tal, o Product Owner é responsável pelo sucesso geral da solução que está sendo desenvolvida ou mantida. Não importa se o foco está em um produto externo ou em uma aplicação interna; o Product Owner ainda tem a obrigação de garantir que o trabalho mais valioso possível, que pode incluir trabalho com foco técnico, seja sempre realizado.

Framework Scrum

Garante que a equipe construa rapidamente o que o Product Owner deseja. O Product Owner colabora ativamente com o Scrum Master e a equipe de desenvolvimento e deve estar disponível para responder a perguntas logo após elas serem feitas.

Gerenciamento do Product Backlog

Usando o Scrum, sempre fazemos o trabalho mais valioso primeiro. O product owner, com a contribuição do restante da equipe Scrum e das partes interessadas, é o responsável final por determinar e gerenciar a sequência desse trabalho e comunicá-la na forma de uma lista priorizada (ou ordenada) conhecida como backlog do produto. No desenvolvimento de novos produtos, os itens do backlog do produto são, inicialmente, os recursos necessários para atender à visão do product owner. Para o desenvolvimento contínuo do produto, o backlog do produto também pode conter novos recursos, alterações em recursos existentes, defeitos que precisam de reparo, melhorias técnicas e assim por diante. O product owner colabora com as partes interessadas internas e externas para reunir e definir os itens do backlog do produto.

Ele então garante que os itens do backlog do produto são colocados na sequência correta (usando fatores como valor, custo, conhecimento e risco) para que os itens de alto valor apareçam no topo do backlog do produto e os de menor valor apareçam na parte inferior. O backlog do produto é um artefato em constante evolução. Os itens podem ser adicionados, excluídos e revisados ​​pelo proprietário do produto conforme as condições de negócio mudam ou conforme a compreensão da equipe Scrum sobre o produto cresce (por meio de feedback sobre o software produzido durante cada sprint). De modo geral, a atividade de criar e refinar os itens do backlog do produto, estimá-los e priorizá-los é conhecida como preparação.

Dentro de suas capacidades, o PO de um DevTeam:

Gerencia o Produto

O Product Owner mantém um contato frequente com os clientes e demais partes interessadas ao longo de todo o projeto para fazer o levantamento dos objetivos ou necessidades de negócios mais prioritárias do produto em cada momento. Ele decide quais dessas necessidades farão parte do produto e as insere como itens em uma lista, chamada de Product Backlog. Ele ordena, atualiza e reordena esses itens, detalha-os progressivamente à medida que ganham importância e remove aqueles que não mais são necessários e que não devem ser desenvolvidos. Ele também garante a visibilidade do Product Backlog ao Time de Desenvolvimento.

O Product Owner realiza a gestão do produto e tem a palavra final sobre o Product Backlog. Ele é o único que pode alterar o Product Backlog. Nesse trabalho de gestão do produto, é importante que o Product Owner desenvolva algum tipo de estratégia de negócios para o desenvolvimento do produto em direção à Visão do Produto, e utilize essa estratégia para tomar as decisões necessárias quanto ao que será desenvolvido. Essa estratégia, assim como o próprio desenvolvimento do produto, evolui de forma iterativa e incremental. Um formato possível de estratégia de negócios é o Roadmap do Produto, que descreve o futuro do produto em alto nível, apontando uma data provável para cada Release ou para marcos do projeto e a Meta a ser alcançada em cada uma dessas Releases ou marcos.

Além dos clientes do projeto e demais partes interessadas, o Product Owner também ouve o próprio Time de Desenvolvimento para tomar as decisões quanto ao produto. O Time de Desenvolvimento oferece uma visão do que é tecnicamente possível, do custo de desenvolvimento de cada item do Product Backlog e de que trabalho técnico adicional poderá ser necessário. Com relação a essa última questão, cabe ao Time de Desenvolvimento identificar itens de trabalho técnico — como o teste de uma nova ferramenta ou a melhoria de alguma parte do produto, por exemplo — e sugerir ao Product Owner sua inserção no Product Backlog. Cabe ao Product Owner decidir, após entender o que for necessário junto ao Time de Desenvolvimento, se esses itens serão realmente desenvolvidos e quando.

Mantém a visão do produto

Embora não faça parte do framework Scrum, a definição de uma Visão do Produto é uma prática importante para o trabalho no projeto de desenvolvimento de um produto. A Visão do Produto responde à pergunta: “Por que esse produto está sendo desenvolvido?”. Ou, ainda melhor, “Que problema será resolvido com o desenvolvimento desse produto?”. Ela serve de guia para o trabalho do Time de Scrum e alinha o entendimento e as expectativas quanto ao produto entre as diferentes partes interessadas do projeto e o Time de Scrum. Para tornar esse alinhamento possível, o Product Owner comunica a Visão a todos os envolvidos, assegurando que ela seja compreendida da mesma forma por todos.

O Product Owner estabelece a Visão do Produto junto aos clientes e demais partes interessadas do projeto antes do início do desenvolvimento do produto e, portanto, antes do uso do Scrum. Se possível, é importante também envolver o Time de Desenvolvimento nas atividades necessárias para se chegar a essa definição.

O Product Owner é o responsável por manter a Visão do Produto, gerenciando o Product Backlog de forma a garantir que todo o trabalho realizado pelo Time de Desenvolvimento caminhe em direção a ela.

Gerencia a release

A gestão das Releases do produto é uma atribuição do Product Owner. Ele decide qual é a melhor estratégia para realizar as Releases no projeto e a modifica quando necessário. Ele leva em conta também que os princípios Ágeis pregam entregas desde cedo e frequentes para possibilitar o feedback rápido e, assim, reduzir os riscos do projeto.

A estratégia de Releases é condicionada por questões de negócios e questões técnicas. Por um lado, as Releases são alinhadas com a estratégia de negócios do produto, de forma a contribuir com ela. Ao mesmo tempo, para decidir como e quando serão realizadas, o Product Owner também considera questões técnicas, que são apontadas pelo Time de Desenvolvimento e, em muitos casos, pelos próprios clientes ou usuários.

Existem diferentes possibilidades para a estratégia de realização das Releases de um projeto. Por exemplo, elas podem ser realizadas quando o Product Owner julgar adequado, após alguns Sprints, ao final de cada Sprint ou em entrega contínua. As Releases também podem ser realizadas diretamente para seus usuários finais ou para um grupo selecionado desses usuários, ou de usuários intermediários, geralmente internos, dependendo da estratégia do produto.

Colabora com o Time de Desenvolvimento durante o Sprint

Durante o Sprint, para permitir ao Time de Desenvolvimento solicitar esclarecimento ou uma decisão rápida sobre algum item do Sprint Backlog sempre que necessário, o Product Owner se coloca disponível e acessível. De outra forma, ele estaria gerando um impedimento ou estimulando o Time de Desenvolvimento a tomar decisões sobre o produto que não lhe cabem.

É também saudável o Product Owner interagir com o Time de Desenvolvimento durante o Sprint para, juntos, refinarem e prepararem itens no topo do Product Backlog para o Sprint seguinte. Enquanto diversos Times de Scrum realizam essa atividade durante a reunião de Sprint Planning, cada vez mais times utilizam sessões de Refinamento do Product Backlog, realizadas durante o Sprint, para essas atividades.

No entanto, interferências do Product Owner no planejamento já realizado para a Sprint desviam o foco do Time de Desenvolvimento e podem comprometer a realização do trabalho. Assim, o Time de Desenvolvimento, amparado pelo Scrum Master, rejeita durante o Sprint alterações no Sprint Backlog que modifiquem a Meta do Sprint já acordada.

Da mesma forma, o Product Owner que busca informações sobre o andamento do trabalho em direção à Meta do Sprint pode ter o intuito de exercer pressão sobre o Time de Desenvolvimento, interferindo em sua auto-organização. No entanto, o Time de Desenvolvimento pode buscar o feedback do Product Owner no decorrer do Sprint sobre itens em andamento ou já prontos, o que pode ajudá-lo a melhorar sua entrega e a atingir a Meta do Sprint.

Aceita ou rejeita a entrega do Time de Desenvolvimento

O Product Owner tem a responsabilidade de aceitar ou rejeitar os entregáveis que serão demonstrados para os clientes do projeto e demais partes interessadas no final de cada Sprint, durante a reunião de Sprint Review. Essa atividade pode ser realizada na própria reunião, mas o Time de Scrum pode preferir preparar-se antes e chegar à reunião já alinhado sobre os resultados do Sprint.

Apenas os itens prontos, de acordo com a Definição de Pronto, serão aceitos pelo Product Owner, o que inclui, entre outros critérios, que cada item passe pelos Critérios de Aceitação acordados especificamente para ele e tenha qualidade suficiente para ser entregue. Na reunião de Sprint Review, o Time de Desenvolvimento demonstra para os presentes apenas esses itens prontos.

O Product Owner verifica se esses entregáveis são suficientes para cumprir a Meta estabelecida junto ao Time de Desenvolvimento para o Sprint e comunica claramente se essa Meta do Sprint foi cumprida ou não.