Scrum Master vs Product Owner: Comparação dos Papéis

O Product Owner é responsável por maximizar o valor do produto e por gerenciar o que entra no backlog: o "o quê" e o "porquê". O Scrum Master é responsável pela eficácia do Scrum Team e por como o time trabalha: o "como", não o "o quê". Se você confundir esses dois pontos, quase todas as outras dúvidas sobre os dois papéis surgem a partir daí.

Essa confusão é comum o bastante para que valha a pena ser preciso desde o início, porque na prática os dois papéis se misturam o tempo todo, seja quando um Scrum Master reordena o backlog em silêncio porque o Product Owner está lento, seja quando um Product Owner conduz a Daily Scrum como uma reunião de status porque ninguém lhe disse que não deveria.

Fatos principais

• O Scrum Guide de 2020 afirma que o Scrum "define três responsabilidades específicas dentro do Scrum Team: os Developers, o Product Owner e o Scrum Master", uma redação que substituiu o termo "papéis" das edições anteriores.
• Segundo o Guide, o Product Owner "é responsável por maximizar o valor do produto resultante do trabalho do Scrum Team", enquanto o Scrum Master "é responsável pela eficácia do Scrum Team".
• Um Scrum Team é "tipicamente composto por 10 pessoas ou menos", segundo o Scrum Guide de 2020, pequeno o bastante para que as duas responsabilidades fiquem dentro de um único time, e não em uma camada de gestão acima dele.
• O Large-Scale Scrum (LeSS) mantém exatamente um Product Owner para todos os times que constroem um único produto, com o argumento de que dividir o backlog entre vários Product Owners fragmenta as prioridades.

Duas responsabilidades, não dois papéis

A maioria das comparações entre essas duas posições começa no lugar errado: uma lista simétrica de "o Scrum Master faz X, o Product Owner faz Y", como se ambos estivessem em trilhas paralelas de igual peso. Não estão, e o Scrum Guide de 2020 chegou a mudar sua redação para deixar isso claro. As edições anteriores chamavam Product Owner, Scrum Master e Developers de "papéis". A edição atual não usa essa palavra para nenhum deles. Ela diz que o Scrum "define três responsabilidades específicas dentro do Scrum Team", uma mudança deliberada que muitas explicações concorrentes ainda erram ao voltar a "papéis" por hábito.

A escolha da palavra importa. "Papel" sugere uma descrição de cargo: um conjunto de tarefas atribuídas a uma pessoa. "Responsabilidade" sugere algo mais estreito e mais pesado: uma pessoa responde por um resultado, tenha ou não feito pessoalmente o trabalho por trás dele. Lido assim, a diferença entre esses dois trabalhos deixa de ser uma lista de tarefas e passa a ser uma pergunta sobre o que cada pessoa tem de responder quando algo dá errado.

Se você ainda está conhecendo como o Scrum funciona como framework, vale ler isso antes desta comparação, já que tudo abaixo pressupõe o Sprint, os três artefatos e o Scrum Team pequeno e autogerenciado que ele define. As duas responsabilidades só existem dentro dessa estrutura. Sem o Scrum, nenhum dos dois títulos significa algo específico.

Scrum Master vs Product Owner em resumo

Pelo que o Product Owner realmente responde

Segundo o Guide, "o Product Owner também é responsável pelo gerenciamento eficaz do Product Backlog", o que se desdobra em quatro deveres específicos: desenvolver e comunicar o Product Goal, criar e comunicar os itens do backlog, ordenar o backlog e mantê-lo transparente e compreendido. Traduzida para uma semana real, essa lista se parece menos com burocracia e mais com uma sequência de decisões de julgamento.

Duas frases do Guide fazem mais trabalho do que parece à primeira vista. A primeira: "o Product Owner pode realizar o trabalho acima ou delegar a responsabilidade a outras pessoas. Independentemente disso, o Product Owner continua sendo o responsável." Um Product Owner pode pedir a outra pessoa que escreva as histórias de usuário ou conduza o processo de entrada de demandas. Ele não pode repassar a responsabilidade em si, o que significa que a bola para nele mesmo quando a caneta não está em sua mão.

A segunda: "para que os Product Owners tenham sucesso, toda a organização deve respeitar suas decisões." Isso não é cortesia; é um requisito estrutural. Um Product Owner cuja ordem de backlog é sobrescrita por quem reclama com um VP não é realmente responsável por nada, não importa o que diga o título. Se isso acontece no seu time, o título é decorativo.

Pelo que o Scrum Master realmente responde

A responsabilidade do Scrum Master se divide em serviço a três públicos diferentes: o Scrum Team, o Product Owner e a organização. Essa divisão em três é fácil de perder se você pensa no Scrum Master apenas como "a pessoa que conduz o stand-up".

Repare no que não está nessa lista: escrever relatórios de status para a gestão, ser dono de uma data de entrega ou decidir o que o time constrói. Essas tarefas são absorvidas pelo papel o tempo todo na prática, e é exatamente assim que um Scrum Master vira um coordenador de projeto com outro título. Segundo o Guide, a responsabilidade é a eficácia do time, ponto final, e não uma função de reporte anexada a ela.

Onde os dois colidem e como times saudáveis resolvem isso

Esta é a parte que a maioria das comparações pula, e é a que mais importa no dia a dia. As duas responsabilidades não são adversárias por desenho, mas puxam em direções diferentes com frequência suficiente para que o atrito seja normal, e não sinal de que algo está quebrado.

O padrão por trás das cinco linhas: o trabalho do Product Owner é defender o valor e andar rápido, e o trabalho do Scrum Master é proteger a capacidade do time de entregar esse valor de forma sustentável. Nenhum dos dois instintos está errado por si só. O atrito é o sistema funcionando, e não falhando, desde que uma pessoa não simplesmente atropele a responsabilidade da outra para fazer a tensão desaparecer.

Evento por evento do Scrum: quem faz o quê

As duas responsabilidades aparecem em todos os eventos, mas em posturas diferentes. Uma traz o conteúdo, a outra protege o recipiente em que ele acontece.

Uma pessoa pode fazer os dois?

Às vezes, e geralmente isso não se sustenta por muito tempo. As duas responsabilidades puxam em sentidos opostos por estrutura: o trabalho do Product Owner recompensa dizer sim ao valor e andar rápido, enquanto o do Scrum Master recompensa proteger o ritmo do time e resistir quando a velocidade ameaça a qualidade. Coloque os dois incentivos na cabeça de uma só pessoa e um lado quase sempre vence por padrão, geralmente aquele com a pressão mais alta e mais imediata (o prazo de uma parte interessada costuma vencer uma conversa de coaching pouco glamorosa).

A cláusula de delegação do Guide piora a situação de um papel combinado, em vez de melhorá-la. Delegar tarefas não reduz a responsabilidade total, apenas concentra dois tipos distintos de responsabilidade em uma única agenda. Alguém que acumula Product Owner e Scrum Master não está fazendo metade de dois trabalhos; é totalmente responsável pelos dois, com as horas de uma pessoa.

Vale separar isso de outro tipo de compressão de papéis. O Large-Scale Scrum (LeSS) mantém deliberadamente um único Product Owner para muitos times que constroem um só produto, mas pelo motivo oposto: evitar que as prioridades se fragmentem entre backlogs concorrentes, e não economizar headcount. É um Product Owner cobrindo mais times, não uma pessoa cobrindo duas responsabilidades diferentes. Se a sua organização está crescendo além de um único time, vale ler sobre o LeSS e abordagens semelhantes de escala antes que alguém improvise um papel combinado por necessidade.

Onde isso se sustenta: times muito pequenos e de baixo conflito, tratado explicitamente como um arranjo temporário, revisto assim que o time ou a lista de partes interessadas crescer. O modo de falha não é tentar. É nunca planejar desfazer a combinação.

Scrum Master e Product Owner vs Gerente de Projetos e Gerente de Produto

Nem o Scrum Master nem o Product Owner são um gerente de projetos com outro nome, embora ambos absorvam em silêncio partes desse trabalho na prática. E o Product Owner já tem uma comparação completa com o Product Manager em outro lugar: leia Product Owner vs Product Manager para entender a assimetria entre responsabilidade e cargo que gera a maior parte dessa confusão (resumindo: o Product Owner é definido por um único documento, o Product Manager não é definido por nenhum).

A comparação do Scrum Master com o gerente de projetos é uma divisão mais limpa, porque os dois trabalhos quase não se sobrepõem no que controlam.

Para um quadro mais completo de onde o gerenciamento de projetos e de programas se afasta de qualquer uma das responsabilidades do Scrum, veja nossa comparação entre gerenciamento de programas e de projetos.

Qual contratar primeiro, ou qual se tornar

Antipadrões comuns

Nada disso se resolve em uma decisão permanente de organograma, tomada uma vez e esquecida. Times mudam de tamanho, produtos mudam de estágio, e os pontos de atrito da tabela de colisões acima voltam toda vez que algo muda, seja uma nova parte interessada, um backlog crescente ou um time que superou um papel combinado com o qual começou por necessidade. O caminho mais rápido de volta à clareza, quando isso acontece, não é um novo debate sobre títulos. É voltar à frase em que cada responsabilidade foi construída: quem responde pelo valor do produto e quem responde pela capacidade do time de entregá-lo.

Seja qual for o lado que você está resolvendo, seja contratando, desfazendo a confusão de um time ou escolhendo um caminho de carreira, a frase a que vale sempre voltar é a que o Guide de fato escreveu: uma pessoa responde pelo valor do produto, a outra pela eficácia do time. Todo o resto é detalhe.