Guia do Scrum Comentado
O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto resultado do trabalho do Time de Desenvolvimento.
Normalmente usamos o criador do Plano do Projeto, um cliente ou alguém que entenda e defenda a visão para manter o foco no retorno sobre o investimento.
Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos.
O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto.
O gerenciamento do Backlog do Produto inclui:
• Expressar claramente os itens do Backlog do Produto;
• Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;
• Otimizar o valor do trabalho que o Time de Desenvolvimento realiza;
• Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e,
• Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.
O Product Owner pode fazer o trabalho acima, ou delegar para o Time de Desenvolvimento fazê-lo. No entanto, o Product Owner continua sendo o responsável pelos trabalhos.
Na prática, todo o Time Scrum colabora com o Backlog, mas a priorização dos itens, ainda é responsabilidade do Product Owner, assim como deixar claro o propósito do projeto e de cada Sprint.
O Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem endereçar ao Product Owner.
Qualquer um pode colocar mudanças, bugs, novos itens no Backlog. O que vai ser feito e em qual prioridade é decisão do Product Owner.
Para que o Product Owner tenha sucesso, toda a organização deve respeitar as decisões dele(a). As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog do Produto.
Toda mudança de prioridade e escopo devem ser tratadas diretamente com o Product Owner.
Ninguém pode forçar o Time de Desenvolvimento a trabalhar em um diferente conjunto de requerimentos.
Isso garante o compromisso e foco do Time.
Este artigo faz parte das minhas anotações sobre o Guia do Scrum, um capítulo em cada artigo, e se possível com exemplos práticos. Onde estiver em itálico é o texto do Guia, senão são minhas anotações.
