O papel de um Product Owner
de acordo com o Guia Scrum
De todos os papéis do Scrum, o proprietário do
produto desempenha o papel mais significativo. Além
de entender e promover a visão de produto do cliente
para a equipe, o PO também promove um ambiente de
trabalho saudável e garante que o projeto seja
concluído no prazo. Acima de tudo, o PO também é
responsável pelo sucesso e fracasso do projeto.
Portanto, a pessoa indicada como PO deve possuir
certas características que constituem um grande
líder - o proprietário do produto lidera toda a
equipe Scrum.
Então, o que faz um bom proprietário do produto? Que
virtudes ele ou ela deve possuir? A melhor maneira
de saber sobre o tipo de papel que um PO deve
desempenhar idealmente é voltar ao guia oficial do
Scrum e descobrir o que ele tem a dizer sobre o
papel de um product owner.
Crie os itens do backlog do produto ou histórias do
usuário no backlog
Uma das maiores responsabilidades de um PO é decidir
quais recursos do produto devem ser desenvolvidos no
projeto e representar esses recursos na forma de
histórias de usuários ou itens do backlog do produto
no backlog. O proprietário do produto é responsável
pelo backlog do produto e o "possui" em nome das
partes interessadas e dos clientes. Não é necessário
que o PO crie pessoalmente as histórias do usuário e
as defina no backlog. O guia oficial do Scrum
afirma.
O Product Owner é responsável pelo Product Backlog,
incluindo seu conteúdo, disponibilidade e pedidos."
Embora o guia generalize ainda mais o papel de uma
OP como
"O Product Owner é a única pessoa responsável por
gerenciar o Product Backlog."
Não é necessário que o PO crie o backlog do produto
sozinho. O PO é responsável pelo backlog. Ele/ela
pode ter a ajuda dos membros da equipe e do Scrum
master enquanto cria o backlog. Em certos tipos de
implementação do Scrum, o PO supervisiona a criação
do backlog enquanto a equipe realmente define os
itens do backlog do produto de acordo com as
instruções e diretrizes do PO. Como o Scrum é um
framework, seus princípios fundamentais devem ser
aplicados em um projeto antes que seus benefícios
possam ser aproveitados. Além disso, o Scrum deve
ser implementado de acordo com os requisitos do
projeto e, portanto, há muito escopo de como o PO
pode cumprir suas responsabilidades.
Ordene e priorize o backlog do produto.
Em sua forma mais fundamental, um backlog de produto
é simplesmente uma lista ordenada de tudo o que é
necessário para desenvolver o produto. A lista
funciona como uma fonte única de requisitos para
desenvolver o produto em sua totalidade, ou seja,
inclui a funcionalidade, critérios de aceitação,
descrição e aspectos de documentação necessários
para tornar o produto despachável. O guia afirma
"O Product Backlog lista todos os recursos, funções,
requisitos, aprimoramentos e correções que
constituem as alterações a serem feitas no produto
em versões futuras. Os itens do Product Backlog têm
os atributos de uma descrição, pedido, estimativa e
valor."
Na vida real, o backlog do produto é dinâmico por
natureza e nunca completo.
O Product Backlog é uma lista ordenada de tudo o que
pode ser necessário no produto e é a única fonte de
requisitos para quaisquer alterações a serem feitas
no produto. Um Product Backlog nunca está completo.
O desenvolvimento inicial apenas estabelece os
requisitos inicialmente conhecidos e mais bem
compreendidos. O Product Backlog evolui à medida que
o produto e o ambiente em que será usado evoluem. O
backlog do produto é dinâmico por natureza - ele
continua mudando constantemente para identificar o
que o produto realmente precisa para ser apropriado,
competitivo e útil. Enquanto um produto existir, seu
backlog de produto também existirá.
Projete e planeje uma meta de sprint adequada
Como o backlog do produto é principalmente
"propriedade" do PO, ele ou ela é responsável por
entregar uma versão de produto estável e livre de
bugs e garantir que o projeto seja concluído a
tempo. No Scrum, uma vez que toda a atividade de
desenvolvimento é realizada através dos sprints
diários, é muito importante projetar um sprint de
forma que seu objetivo seja devidamente satisfeito e
cumprido ao final do ciclo iterativo. O PO transmite
a visão do produto para a equipe, e uma das tarefas
importantes por ele desempenhadas é projetar e
planejar uma meta de sprint adequada. O guia diz:
O Sprint Goal é um objetivo definido para o Sprint
que pode ser alcançado através da implementação do
Product Backlog.
Ele fornece orientação para a equipe de
desenvolvimento sobre o motivo pelo qual está
construindo o incremento.
O objetivo do sprint é decidido durante o evento de
planejamento do sprint. O objetivo principal de ter
um objetivo de sprint bem definido é garantir que a
equipe de desenvolvimento permaneça focada em como
deve desenvolver as histórias de usuário e quais
critérios as histórias devem atender para serem
consideradas "entregáveis". O objetivo do sprint
inclui os critérios de aceitação - condições
especificadas nos itens do backlog do produto que
devem ser satisfeitas para que o recurso do produto
desenvolvido pela equipe possa entregar um
determinado valor de negócio ao cliente. Como o PO é
a pessoa mais familiarizada com o que o produto
final deve entregar idealmente em termos de
funcionalidade, o sucesso do sprint depende muito de
como o PO definiu o objetivo do sprint. Muito
depende de quão bem a equipe entende a visão do
produto e o objetivo do sprint, e é o PO'
Garantir que a equipe de desenvolvimento entenda os
itens do Product Backlog no nível necessário.
Esteja disponível para a equipe
O Agile Scrum defende a auto-organização e o
autogerenciamento. As equipes Scrum são
multifuncionais e capazes de trabalhar de forma
independente. Na prática, o Scrum master
supervisiona a implementação do Scrum e garante que
a equipe não enfrente nenhum impedimento. No
entanto, se e quando a equipe enfrentar um problema
ou uma situação técnica, o Scrum master pode buscar
a orientação do PO e pedir uma solução caso a equipe
não consiga resolver o problema por conta própria.
Além disso, para questões relacionadas ao feedback
do cliente ou das partes interessadas, o PO faz a
ligação entre a equipe e a gestão para apresentar
uma solução aceitável.
A OP deve permanecer acessível, se não fisicamente,
pelo menos ser acessível usando dispositivos de
comunicação eletrônica e recursos de bate-papo
on-line para resolver problemas. A equipe deve poder
se comunicar livremente e transmitir os problemas ao
PO quando necessário. O PO deve estar disponível
quando a equipe precisar de sua presença.
Se possível, participe dos scrums diários
O stand up diário ou o Scrum diário é mais um evento
de equipe de desenvolvimento-Scrum master no qual o
SM faz o que deve fazer no Scrum - supervisionar que
os princípios básicos do Agile sejam seguidos
adequadamente pela equipe e o feedback das
informações ciclo é mantido. O guia oficial do Scrum
não sugere nada sobre se um PO deve participar do
scrum diário ou não. Não é obrigatório que o PO
compareça a este evento, no entanto, se o PO tomar a
iniciativa e participar das Scrums diárias, isso
melhoraria a experiência do Scrum, pois se fosse o
caso, a equipe estaria inclinada a assumir o
processo mais a sério. A melhor maneira de liderar
uma equipe é dar o exemplo, fazendo algo primeiro e
motivando a equipe a segui-lo.
Além disso, há uma vantagem adicional se o PO
participar do Scrum diário. É possível ter uma ideia
muito melhor sobre como a equipe está se saindo e
que tipos de problemas a equipe está enfrentando
atualmente participando dos stand ups. O PO fica
mais bem informado e, como resultado, os princípios
de inspeção e adaptação podem se tornar mais
eficazes.