Muito boas suas respostas. Posso dizer que foram bem esclarecedoras e concordo com tudo.

Abraço.

Vou tentar tirar as dúvidas de forma bastante objetiva.

P: O P.O. é o cliente? Cliente e P.O. são as mesmas coisas? O P.O. tem que ser necessariamente o representante do cliente?
R: Pode ser caso ele tenha conhecimento em como agir quando no estado de Product Owner de um projeto. Depende. Não. O Cliente é quem espera pela produto de acordo com sua visão inicial de negócio e P.O é o responsável por gerir os interesses desse cliente, organizá-los de forma a priorizar itens de maior importância , definir metas, verificar ROI e etc. Não. Ele pode ser como já explicado o próprio cliente. Desde que ele possua conhecimento suficiente para exercer o papel de PO.

P: O P.O. precisa entender de software?
R: O P.O precisa entender da visão do produto imaginado pelo cliente.
Precisa entender suas prioridades, suas metas.
Quem precisa entender como desenvolver software é o scrum team.
Entenda, macro-tarefas (P.O), micro-tarefas (Scrum Team), Processos (Scrum Master).

P: É papel do P.O.trazer o que ele quer já detalhado em forma de itens do software a ser desenvolvido ou é papel do Scrum Master entender a necessidade de negócio e traduzir em software?

R: Sim. O P.O é o dono do produto, faz o contato direto com o cliente, portanto ele deve entender quais são os itens de necessidade e tratá-los a ponto de entregá-los de forma granulada, detalhada a equipe.
Se ele não fizer isso, ocorrerá a chegada do que chamamos de EPIC e não Stories e não será possível estimar aquela tarefa devido a disparidade entre uma tarefa detalhada e um EPIC.

P: Dado um cliente externo (ou interno off-site) não se faz necessário designar um “P.O. Interno” que seja um analista e que faça a ponte com o cliente?

R: Errado. Independente de cliente interno ou externo o papel do P.O continua sendo de extrema importância.
O que adianta ter um cliente interno que nunca está disponível?
Nesse caso, podemos patrocinar um outro recurso como P.O para que ele entenda as necessidades desse cliente interno e esteja disponível nas fases necessárias do processo Scrum.

P: O “P.O. Interno” pode ser o Scrum Master, dado o fato de que o Scrum Master entende de tecnologia e é um analista de sistema em geral?
R: Não. O ScrumMaster é um facilitador, um educador, mediador entre equipe e P.O e nunca poderá exercer as duas atividades sob a pena de gerar impedimentos na própria equipe, fazendo com que não atinja a meta traçada por ele mesmo (caso seja o P.O)

P: É responsabilidade do Scrum Master definir o prazo real para o desenvolvimento e demonstrar ao P.O. no Sprint Planning ou é responsabilidade do P.O. ter o entendimento de desenvolvimento para criticar o prazo estipulado?

R: Nenhuma das alternativas. A tarefa de estimar o esforço de desenvolvimento é de responsabilidade do Scrum Team. Nenhum outro ator no processo possui esta responsabilidade. Novamente, estamos falando de micro-tarefas. Quem conhece as micro-tarefas são os desenvolvedores.
O P.O jamais pode criticar o esforço estipulado, este prazo de entrega deve ser acordado entre a equipe + ScrumMaster e o P.O.

Espero ter ajudado.

Abs.
Diego

Muito obrigado!

Vou passar a minha opinião, pela minha experiência e pelas dezenas de relatos e experiencias alheias que tive oportunidade de conhecer através dos livros, blogs e afins.

O PO é aquele responsável pelo ROI do produto. Ele precisar realizar todas as tarefas que estejam ao seu alcance para maximizar o ROI do produto. É disso o que se trata ser Product Owner.

Como ele irá fazer isso é o grande desafio que o PO tem pela frente. Se ele irá designar representantes para responder por ele, participar das reuniões ou definir requisitos, é problema dele. Mas não deveria. Em última análise, o sucesso ou fracasso do produto é de sua INTEIRA responsabilidade. Mas, naturalmente, ele poderá obter ajuda de outros profissionais. Se o produto for muito complexo, poderá criar uma equipe que irá ajudá-lo a criar o produto, incluindo desde especialistas em mercado, passando por profissionais de user experience, até mesmo analistas de requisitos que ajudem a equipe a escrever o backlog. O Scrum Master tem papel fundamental nesse processo, auxiliando o PO a criar o backlog e servindo como ponte entre o PO e a equipe de desenvolvedores quando necessário para especificar requisitos.

Não se define que alguém é o PO e aí se transfere a ele essa responsabilidade. É o contrário. A pergunta é: Quem é o responsável pelo sucesso do produto, pelo seu ROI? A resposta é o PO. Se ele quiser ter um representante ou não, é a forma que ele decidirá trabalhar e deve assumir os riscos da sua decisão.

A pergunta não define bem o que seria “entender” de software, mas certamente o PO precisa conhecer a fundo as capacidades da tecnologia. Não precisa ser um profissional da área, nunca ter programado (apesar de ajudar bastante), mas deve ter um profundo conhecimento das possibilidades que a tecnologia provê, estando sempre atualizado nesse sentido.

A pergunta sobre o prazo está um pouco ambígua. Pode ser sobre o prazo para desenvolver os itens de backlog ou o prazo para entregar um release. O prazo do release quem define é o PO. O prazo para desenvolver os itens de backlog – as estimativas – quem define é o time, e exclusivamente o time e mais ninguém.

Ninguém, repito ninguém, e principalmente o PO, deve jamais criticar as estimativas do time. Sempre que uma estimativa é criticada por ser grande, o time não terá o menor problema em diminuí-la de acordo com a “vontade” do crítico. O problema será na qualidade do código gerado, que precisará se adaptar ao prazo menor. Para bom entendedor meia pala ba…