Scrum — papéis: PO, SM (líder-servidor), Developers; time ≤ 10

A ideia que organiza o assunto

O Scrum tirou o gerente de dentro do time e não colocou ninguém no lugar. Em vez de uma pessoa que decide o que fazer, quando fazer e como fazer, ele partiu essa autoridade em três e deu a cada parte um dono nominal.

É essa partição que organiza o assunto inteiro: cada responsabilização tem um objeto próprio, e nenhuma invade o objeto da outra.

O Product Owner responde pelo produto — o que vale a pena fazer e em que ordem.
O Scrum Master responde pelo processo e pelas pessoas — que o Scrum seja entendido e aplicado, que os eventos aconteçam e sejam úteis, que os impedimentos caiam.
Os Developers respondem pelo como — quanto cabe na Sprint e de que maneira o trabalho vira Incremento.

Guardada essa separação, a maior parte das questões se resolve sem decorar listas. Basta olhar o complemento do verbo. Se o item fala de valor, prioridade, backlog do produto, meta do produto ou rumo, o sujeito legítimo é o Product Owner. Se fala de evento, prática, impedimento, ambiente ou eficácia do time, é o Scrum Master. Se fala de plano da Sprint, estimativa ou técnica, são os Developers. Quando o sujeito escrito no item não bate com o objeto do verbo, o item é Errado — e, nos 27 itens já explicados deste tópico, isso responde por doze dos dezoito erros.

Há um corolário que o candidato precisa carregar inteiro: ninguém manda em ninguém. O Scrum Master não é chefe, não é gerente de projeto e não administra recursos. O Product Owner não dirige a execução. Não existe gerente da Sprint.

Por que se usa (e o que custa)

Ganha-se velocidade de decisão. Priorizar produto é decisão de uma pessoa só, o que elimina o comitê e o ciclo de aprovação; e decidir como fazer é do time que faz, o que elimina o repasse de instruções. Um desvio detectado numa Daily pode ser corrigido no mesmo dia, porque quem detecta é quem decide.

Paga-se em duas moedas. A primeira é autoridade real: o modelo só funciona se a organização respeitar a decisão do Product Owner; onde ele é um intermediário sem poder, o Product Backlog vira fila de pedidos e a Sprint vira lista de tarefas. A segunda é ambiguidade de comando: sem chefe no time, não há a quem escalar um conflito, e é exatamente essa lacuna que o Scrum Master preenche sem autoridade formal, por influência — daí a liderança servidora não ser um enfeite de vocabulário, e sim a peça que sustenta o desenho.

Formulação honesta para a prova: o Scrum troca hierarquia por responsabilização nominal. Ele não elimina a responsabilidade; distribui-a em três endereços e proíbe que qualquer um deles dê ordens aos outros.

Como funciona

O Scrum Team é a unidade. Consiste em um Scrum Master, um Product Owner e os Developers — tipicamente dez pessoas ou menos, pequeno o bastante para permanecer ágil e grande o bastante para completar trabalho significativo. Dentro dele não há subequipes nem hierarquias. É uma unidade coesa de profissionais, focada em um objetivo de cada vez, coletivamente responsável por criar um Incremento de valor a cada Sprint.

O Product Owner é uma pessoa, não um comitê. Ele é responsável por maximizar o valor do produto resultante do trabalho do time, o que se desdobra em quatro atos: desenvolver e comunicar explicitamente a Meta do Produto, criar e comunicar claramente os itens do Product Backlog, ordenar esses itens e manter o Product Backlog transparente e compreendido. Pode delegar a execução desse trabalho, mas continua sendo o responsável. Representa as necessidades de muitos stakeholders no Product Backlog, e é dele — e só dele — a autoridade de cancelar uma Sprint. Para que ele tenha sucesso, a organização precisa respeitar suas decisões.

O Scrum Master é responsável pela eficácia do Scrum Team e por estabelecer o Scrum como definido no Guia. Serve o time treinando-o em autogerenciamento e multifuncionalidade, ajudando-o a focar em Incrementos de alto valor, causando a remoção de impedimentos e garantindo que todos os eventos ocorram e sejam positivos e produtivos. Serve o Product Owner ajudando-o a encontrar técnicas de definição da Meta do Produto e de gestão do Product Backlog. Serve a organização liderando e treinando a adoção do Scrum e removendo barreiras entre stakeholders e o time. É um líder que serve: lidera sem comandar.

Os Developers são os comprometidos com criar qualquer aspecto de um Incremento utilizável a cada Sprint. São autogerenciados: decidem internamente quem faz o quê, quando e como, e ninguém de fora lhes diz como transformar Product Backlog em Incremento. São eles que criam o Sprint Backlog, que é um plano feito por Developers e para Developers; que adaptam o plano diariamente rumo à Meta da Sprint; e que se responsabilizam mutuamente como profissionais. Não há títulos internos — não existe o desenvolvedor sênior que distribui tarefas.

O vocabulário mudou em 2020. A revisão do Guia publicada naquele ano deixou de falar em papéis (roles) e passou a falar em responsabilizações (accountabilities); trocou Time de Desenvolvimento por Developers, o que extinguiu a leitura de que havia um time dentro do time; substituiu auto-organizado por autogerenciado; e acrescentou a Meta do Produto. Nada disso alterou quem faz o quê. A prova continua usando papel com naturalidade, inclusive em itens Certos, de modo que a palavra papel nunca é, por si, o erro.

O que decide os itens

A tabela que decide mais itens que todas as outras coisas somadas — quem responde pelo quê:

	responde por	atos típicos	nunca faz
Product Owner (1 pessoa)	o produto: valor, ordem, escopo do backlog	define a Meta do Produto, cria e ordena itens do Product Backlog, cancela a Sprint, aceita ou recusa o resultado	dizer como fazer, estimar pelo time, facilitar eventos, garantir o framework
Scrum Master (1 pessoa)	o processo e a eficácia do time	remove impedimentos, garante os eventos, treina, promove o ambiente, remove barreiras organizacionais	priorizar backlog, definir meta do produto, chefiar, administrar recursos, dirigir o produto
Developers	o como e o Incremento	criam o Sprint Backlog, estimam, aderem à Definição de Pronto, adaptam o plano diariamente	ordenar o Product Backlog, decidir o valor do negócio

Um × muitos — Scrum Master e Product Owner são um cada. Developers são vários. O time inteiro tem tipicamente dez pessoas ou menos. Não há quarto papel, e em especial não há manager, gerente, patrocinador ou arquiteto-chefe dentro do time.

Product Backlog × Sprint Backlog — a lista de tudo o que o produto pode precisar é do Product Owner; o plano do que será feito nesta Sprint e de que maneira é dos Developers. Identifique de qual das duas listas o item fala antes de julgar quem manda nela.

Meta da Sprint × escopo da Sprint — o escopo pode ser esclarecido e renegociado com o Product Owner durante a Sprint, à medida que se aprende; o que não pode é comprometer a Meta da Sprint. Item que congela o escopo erra tanto quanto item que libera mudança contra a meta.

Líder servidor × chefe — o Scrum Master lidera servindo. Não avalia, não aloca, não distribui tarefas, não responde pelo cronograma. Toda vez que o item o veste de gerente de projeto — recursos, custo, prazo, qualidade, comando — a resposta é Errado.

Scrum Master × gerente de projetos — as atribuições do gerente não migram para o Scrum Master; dissolvem-se entre os três: escopo e valor vão para o Product Owner, plano e execução vão para os Developers, e ao Scrum Master resta o processo.

Autogerenciamento × auto-organização — mesma prova, redações de anos diferentes: ninguém de fora do time decide o como.

Responsabilidade coletiva × individual — o Scrum define responsabilizações de papel, e a responsabilidade pelo Incremento é do time inteiro. Não há dono de tarefa nem título especializado dentro dos Developers.

Quem participa de quê — a Daily é dos Developers; Product Owner e Scrum Master só entram como obrigatórios se estiverem trabalhando em itens do Sprint Backlog. A Sprint Review reúne o Scrum Team com os stakeholders. A Retrospectiva é do Scrum Team.

Números que caem


responsabilizações no Scrum Team	3 — Scrum Master, Product Owner, Developers
Product Owner · Scrum Master	1 cada, sempre uma pessoa
tamanho do Scrum Team	tipicamente 10 pessoas ou menos
subequipes e hierarquias dentro do time	0
quem pode cancelar a Sprint	1 — apenas o Product Owner
pilares · valores	3 · 5
revisão do Guia que trocou papéis por responsabilizações	2020

Como a CEBRASPE derruba você aqui

Medido sobre os 27 itens do tópico, 18 deles errados. Um único formato responde por dois terços dos erros, e ele tem direção.

A função certa no papel errado — 12 de 18 (67%), e o ímã é o Scrum Master. Em oito desses doze o Scrum Master recebe algo que não é dele, quase sempre poder sobre o produto: “O Scrum master tem a função de criar e comunicar claramente os itens do product backlog”, “o papel do scrum master” é maximizar o valor do produto, “o Scrum Master” tem a responsabilidade de direcionar o rumo do desenvolvimento, “responsável por informar o product owner sobre o que deve ser adicionado ao product backlog”, “o ponto central que detém poderes de liderança sobre o produto”, “liderar o time de desenvolvimento e administrar os recursos do grupo”, “da mesma forma que cabe ao Scrum master” gerenciar escopo, cronograma, custo e qualidade. O movimento inverso — tirar algo do Scrum Master e dar a outro — aparece uma única vez, em “O dono do produto” é responsável por garantir que os ritos sejam adotados. Os três casos restantes deslocam funções entre Product Owner, Developers e figuras inventadas: “A equipe de desenvolvimento” controla e prioriza a lista do produto, “o Product Owner é o gerente da sprint”, e a Daily em que “se faz necessária a presença do product owner e do scrum master”.

A defesa é mecânica e vale para todos os doze: sublinhe o sujeito, depois sublinhe o objeto do verbo. Produto, valor, prioridade, backlog do produto, meta do produto, rumo, recursos, chefia pertencem ao Product Owner ou a ninguém; evento, prática, impedimento, ambiente, eficácia pertencem ao Scrum Master. Se os dois sublinhados não combinam, o item acabou.

O teste do sujeito Scrum Master, isolado, acerta 11 de 11. Nos onze itens em que o Scrum Master é o sujeito da frase, os três Certos lhe dão verbos de processo e de gente — “remover impedimentos, facilitar eventos do Scrum e garantir que a equipe siga os valores”, “ser o guardião dos processos, sem atuar como chefe”, “promove um ambiente em que um product owner ordena o trabalho” — e os oito Errados lhe dão verbos de produto ou de autoridade. Não houve exceção no corpus.

Autoridade repartida entre papéis — 2 de 18. O item copia a regra certa e acrescenta companhia: “tanto as partes interessadas quanto o Scrum master” poderiam cancelar a Sprint, “o Scrum master e demais interessados no produto” definiriam o Product Backlog. A defesa é a frase do Guia: o Product Owner é uma pessoa, não um comitê. Toda redação que reparte decisão sobre o produto entre papéis é Errada.

Número da composição alterado — 2 de 18. “quatro papéis: scrum master, product owner, manager e developers” e “dois product owners e três desenvolvedores”. São três responsabilizações, um Product Owner e um Scrum Master; o único número aberto é o de Developers, com teto sugerido de dez para o time todo. Note que nos dois casos o erro vem acompanhado de um papel de gestão importado de fora.

Inversão de um par — 1 de 18. “existem responsabilidades individuais e não papéis”: é o contrário. Quando o item opuser dois termos com e não, leia a frase invertida antes de julgar.

Consequência inventada a partir de premissa verdadeira — 1 de 18. “se subdivida em subtimes, de modo a maximizar o paralelismo de execuções” — a premissa (reduzir desperdício) veio do Guia, a conclusão contradiz o Guia. Leia a oração iniciada por assim, logo ou de modo a como se fosse um item separado.

Sobre os nove Certos, duas regularidades úteis. Seis deles são frases quase literais do Guia, o que torna o reconhecimento de vocabulário oficial um atalho legítimo: “Não existem subequipes ou hierarquias dentro de um time Scrum”, “o product owner ordena o trabalho para um problema complexo, enquanto o Scrum team e seus stakeholders inspecionam os resultados”, “o escopo pode ser esclarecido e renegociado com o product owner”. E o prior de outros tópicos de TI — frase restritiva tende a ser Errada — falha aqui: das cinco frases restritivas ou negativas do tópico, três são Certas, porque a restrição é do próprio Guia (sem atuar como chefe, não existem subequipes, desde que nenhuma mudança comprometa a meta da sprint), e as duas Erradas são absolutos inventados pelo elaborador (o time Scrum é fixo, faz-se necessária a presença). A pergunta certa não é se há um absoluto na frase, e sim de quem é o absoluto.

O que o tópico não cobra. Nenhum dos 27 itens testa a troca de vocabulário de 2020 em si: papel aparece em cinco enunciados e jamais é o erro — num deles é justamente a palavra correta que o item nega. Nenhum item testa o teto de dez pessoas, nenhum testa as três perguntas removidas da Daily e nenhum usa a expressão líder servidor, embora três cobrem a substância dela. Cinco itens se apoiam em texto que só existe a partir da revisão de 2020 — a definição de Scrum, o ambiente promovido pelo Scrum Master, a Meta do Produto, o termo Developers —, mas em nenhum deles o gabarito mudaria se valesse a redação anterior.

Erros clássicos

Achar que o Scrum Master é o gerente do projeto com outro nome. É o erro mais caro do tópico. Ele não aloca pessoas, não controla cronograma, não responde por custo e não avalia ninguém. Se a atribuição descrita caberia num plano de projeto do PMBOK, ela não é dele.

Confundir as duas listas. Product Backlog é tudo o que o produto pode precisar, e é do Product Owner. Sprint Backlog é o plano desta Sprint, e é dos Developers. Metade dos itens sobre priorização depende só disso.

Tratar o Product Owner como porta-voz do cliente sem poder. Ele representa os stakeholders, mas a decisão é dele e a organização deve respeitá-la. Não é comitê, não divide a caneta e não precisa de referendo.

Supor que autogerenciamento significa ausência de responsabilidade. O time decide o como justamente porque responde coletivamente pelo Incremento. Liberdade e responsabilização são o mesmo movimento.

Importar um quarto papel. Gerente, patrocinador, arquiteto-chefe, líder técnico: nenhum existe dentro do Scrum Team. Quando aparecerem num enunciado, vieram do elaborador.

Imaginar hierarquia dentro dos Developers. Não há títulos, não há subequipes e não há quem distribua tarefas. Sênior e júnior são categorias da empresa, não do framework.