A maioria das equipes ágeis usa Scrum, e os papéis do Scrum são exatamente três: um Product Owner, um Scrum Master e os Developers (os desenvolvedores), que fazem o trabalho. Todas as outras pessoas com interesse no produto, dos clientes aos gestores, trabalham com a equipe, mas não fazem parte dela.
Os papéis são fáceis de listar e fáceis de confundir. O Product Owner vira um comitê, o Scrum Master vira quem faz a ata das reuniões, e os Developers ficam esperando alguém dizer o que fazer em seguida. Este guia explica pelo que cada papel responde e o que decide, segundo o Guia do Scrum, quem mais trabalha ao redor da equipe, como ficam os papéis no Kanban e quem faz o quê em cada reunião, com uma equipe de exemplo.
Os três papéis do Scrum em resumo
| Papel | Responsável por | Decide | Não é |
|---|---|---|---|
| Product Owner | O valor do produto: a Meta do Produto e o Product Backlog | Em que a equipe trabalha em seguida e em que ordem | Um comitê, nem um intermediário que não pode dizer não |
| Scrum Master | A eficácia da equipe e o bom uso do Scrum | Nada sobre o produto; ajuda a equipe a decidir como melhorar | O chefe da equipe, nem o secretário dela |
| Developers | Um incremento utilizável a cada sprint, que atende à Definição de Pronto (Definition of Done) da equipe | Como fazer o trabalho e quem faz cada parte | Pessoas que esperam receber tarefas |
A edição de 2020 do Guia do Scrum chama esses papéis de responsabilidades (accountabilities), e trocou o antigo “Time de Desenvolvimento” por “Developers”, para que o time Scrum seja um só time, sem outro time dentro dele. A maioria das pessoas ainda fala em papéis, e este guia também.
Product Owner
O Product Owner é responsável pelo valor do que a equipe constrói. Na prática, isso significa cuidar do Product Backlog, a lista única e ordenada de tudo de que o produto pode precisar, e ser quem decide o que vai para o topo. O Guia do Scrum divide esse trabalho em quatro partes:
- Definir a Meta do Produto (Product Goal), o objetivo de mais longo prazo que orienta o backlog, e garantir que todos a conheçam.
- Escrever os itens do backlog, ou garantir que alguém os escreva, para que a equipe entenda para que serve cada um.
- Ordenar o backlog, para que o trabalho mais valioso venha primeiro.
- Manter o backlog visível e compreensível para todos que têm interesse nele.
O Product Owner é uma pessoa, não um comitê. Vendas, suporte e o CEO podem tentar mudar a ordem do backlog, mas fazem isso convencendo o Product Owner. O Product Owner pode delegar parte do trabalho, como escrever os itens, e continua respondendo pelo resultado. Por isso o papel pede alguém com autoridade para dizer não, e com tempo para conversar com clientes e stakeholders toda semana.
Scrum Master
O Scrum Master é responsável pela eficácia da equipe e por ela usar o Scrum como ele deve ser usado. O Guia do Scrum diz que os Scrum Masters são “verdadeiros líderes que servem ao Scrum Team e à organização como um todo”, e esse serviço vai em três direções:
- Para a equipe: orienta a equipe a se autogerenciar, mantém o foco em terminar trabalho que atenda à Definição de Pronto, faz com que os impedimentos sejam removidos e garante que as reuniões aconteçam, sejam úteis e não estourem o tempo.
- Para o Product Owner: ajuda a encontrar formas de definir a Meta do Produto e de manter o backlog claro e ordenado.
- Para a organização: ajuda os gestores e as outras equipes a entender como a equipe trabalha, e remove os obstáculos entre eles.
Um Scrum Master não distribui tarefas, não define prazos nem reporta o desempenho das pessoas. Quando a equipe pergunta “quem deveria pegar isto?”, um bom Scrum Master devolve a pergunta para a equipe. Um Scrum Master pode atender mais de uma equipe e, em equipes pequenas, muitas vezes também põe a mão na massa: o Guia do Scrum diz que, se o Product Owner ou o Scrum Master trabalham em itens da sprint, eles participam como Developers.
Developers
Os Developers são todas as pessoas da equipe que constroem o produto: engenheiros, designers, testadores, redatores, analistas. O nome não tem a ver com código. Juntos, eles são responsáveis por:
- Planejar a sprint: escolher o trabalho e decidir como fazê-lo.
- Construir de acordo com a Definição de Pronto da equipe, o padrão comum que diz quando um trabalho está terminado.
- Ajustar o plano todos os dias para alcançar a Meta da Sprint.
- Cobrar esse padrão uns dos outros.
Os Developers se autogerenciam. Ninguém de fora da equipe diz quem faz cada tarefa; eles decidem juntos e dividem a responsabilidade pelo resultado. A equipe também é multifuncional: entre todos, os Developers têm todas as habilidades necessárias para terminar um item, então nada fica esperando uma equipe separada de design ou de testes.
Qual é o tamanho de uma equipe ágil?
O Guia do Scrum diz que um time Scrum tem “normalmente 10 ou menos pessoas”, contando o Product Owner e o Scrum Master. A edição anterior falava em três a nove Developers. Acima disso, a comunicação fica lenta e a reunião diária deixa de ser útil. Quando um produto precisa de mais gente, divida as pessoas em várias equipes que compartilham a mesma Meta do Produto, o mesmo Product Backlog e o mesmo Product Owner.
Os papéis ao redor da equipe
O Scrum só define os três papéis dentro da equipe. Muitas outras pessoas influenciam o trabalho de fora dela:
- Clientes, usuários e patrocinadores. As pessoas para quem o produto é feito e as que pagam por ele. Elas veem os resultados na sprint review, e o feedback delas muda o que o Product Owner coloca em seguida.
- Gestores. Os gestores diretos continuam contratando, desenvolvendo as pessoas e resolvendo os problemas que a equipe não consegue resolver sozinha, como uma habilidade que falta ou duas prioridades em conflito. Eles não distribuem o trabalho da sprint.
- Gerentes de projetos. O Scrum não tem o papel de gerente de projetos: o Product Owner cuida do escopo e das prioridades, os Developers cuidam do plano e o Scrum Master cuida do processo. Na prática, os gerentes de projetos muitas vezes viram Product Owners ou Scrum Masters, ou coordenam o que envolve várias equipes, como orçamentos, fornecedores e datas de lançamento.
- Agile coaches. Coaches que trabalham com várias equipes e com a liderança, geralmente quando a empresa inteira muda o jeito de trabalhar.
- Especialistas compartilhados. Um especialista em segurança ou um analista de dados que ajuda várias equipes trabalha com cada uma quando precisa, sem ser um dos seus Developers.
Os frameworks para escalar o ágil para muitas equipes acrescentam papéis para coordená-las; o mais conhecido é o Release Train Engineer do SAFe. Uma equipe sozinha não precisa de nenhum deles.
Papéis no Kanban
O Kanban não prescreve nenhum papel. O Guia Kanban (em inglês) pede que a equipe torne o trabalho visível, limite o trabalho em progresso e gerencie ativamente o fluxo do trabalho, e não diz nada sobre cargos. Uma equipe que adota o Kanban mantém os papéis que já tem.
O Método Kanban, da Kanban University, descreve dois papéis opcionais, que correspondem bem aos do Scrum: o service request manager, que decide qual trabalho entra em seguida, como um Product Owner, e o service delivery manager, que mantém o trabalho fluindo, como um Scrum Master.
Exemplo: uma sprint na Kestrel Travel
A Kestrel Travel é uma empresa fictícia com um app de viagens. A equipe de check-in tem sete pessoas e trabalha em sprints de duas semanas rumo a uma única Meta do Produto: o viajante pode fazer o check-in de qualquer voo pelo app.
| Pessoa | Papel | O que mais faz |
|---|---|---|
| Ana | Product Owner | Conversa toda semana com os viajantes e com a equipe de parcerias com as companhias aéreas |
| Ravi | Scrum Master | Também atende a equipe de pagamentos |
| Lena, Marco, Joy | Developers | Os engenheiros de iOS, Android e back-end |
| Sam | Developer | O designer |
| Kofi | Developer | Testa o app em celulares de verdade |
Para a sprint 9, Ana propõe o próximo passo de maior valor: um viajante com uma passagem só de ida pode fazer o check-in e guardar o cartão de embarque no celular. Veja quem faz o quê em cada reunião da sprint:
| Reunião | Ana, Product Owner | Ravi, Scrum Master | Os Developers |
|---|---|---|---|
| Sprint planning | Explica por que o check-in só de ida é o mais importante agora, e responde às perguntas | Mantém a reunião dentro do tempo e garante que ela termine com um plano | Escolhem os itens que conseguem terminar, combinam a Meta da Sprint com Ana e planejam o trabalho dos primeiros dias |
| Daily scrum | Não precisa participar | Garante que ela aconteça e não passe de 15 minutos | Verificam o avanço rumo à Meta da Sprint e mudam o plano se precisarem |
| Refinamento do backlog | Explica os próximos itens e reordena o backlog | Ensina a equipe a dividir itens grandes | Fazem perguntas, estimam os itens e dividem os que são grandes demais |
| Sprint review | Convida os stakeholders e discute o que muda no backlog | Facilita, se a equipe quiser | Mostram o check-in funcionando e ouvem o feedback dos stakeholders |
| Retrospectiva | Participa como membro da equipe | Facilita | Escolhem uma ou duas mudanças para testar na próxima sprint |
No segundo dia, Joy descobre que a equipe ainda não tem uma conta de teste para o sistema de check-in da companhia aérea. Ela levanta o problema na daily scrum, e Ravi assume: conseguir a conta agora é trabalho dele, para que os Developers não passem a sprint correndo atrás disso.
Organize os papéis no Redbooth
Os papéis se mantêm com mais facilidade quando o quadro mostra quem cuida do quê. No Redbooth, a equipe da Kestrel usa um espaço de trabalho (em inglês) para o produto de check-in, com a equipe inteira como membros, e três listas de tarefas:
- Product Backlog, mantido por Ana. Cada item é uma tarefa, com os detalhes na descrição e as perguntas nos comentários. Ana mantém os itens mais valiosos no topo.
- Uma lista por sprint. Na sprint planning, os Developers movem para a “Sprint 9” os itens que escolhem, dividem cada um em subtarefas, atribuem as tarefas a si mesmos e dão a cada tarefa datas dentro da sprint.
- Impedimentos, sob a responsabilidade de Ravi. Tudo o que bloqueia a equipe vira uma tarefa atribuída a ele, para que ninguém precise levantar o mesmo problema em toda daily scrum, e todos possam ver quando ele foi resolvido.
Na visualização de quadro, as três listas ficam lado a lado, e cada cartão mostra quem é o responsável:
Se a equipe registrar os papéis por escrito, o lugar deles é um team charter (em inglês), o documento de acordos da equipe, junto com a forma como ela vai decidir quando houver discordância.
Erros que confundem os papéis
- Um comitê no papel de Product Owner. Quando três gestores dividem o papel, o backlog fica sem ordem, e a equipe aprende a esperar que eles cheguem a um acordo.
- Um Product Owner que não pode decidir. Um intermediário que confere cada escolha com outra pessoa atrasa todas as sprints.
- Um Scrum Master que age como chefe. Distribuir tarefas e cobrar prazos ensina a equipe a deixar de se autogerenciar.
- Equipes dentro da equipe. Um grupo de testes separado no fim da sprint traz de volta as passagens de bastão que o Scrum quer eliminar.
- Pessoas espalhadas por equipes demais. Quem está em quatro equipes não pertence a nenhuma, e cada equipe planeja contando com a ausência dela.
Perguntas frequentes
Quais são os três papéis do Scrum?
O Product Owner, que decide em que a equipe trabalha e em que ordem; o Scrum Master, que torna a equipe eficaz; e os Developers, que constroem o produto. O Guia do Scrum chama esses papéis de responsabilidades.
Quem são os membros de uma equipe ágil?
Todas as pessoas necessárias para transformar os itens do backlog em um resultado pronto e utilizável. No Scrum, são o Product Owner, o Scrum Master e os Developers, normalmente 10 pessoas ou menos no total. Clientes, patrocinadores e gestores trabalham perto da equipe, mas não fazem parte dela.
O Scrum Master é um gerente de projetos?
Não. Um Scrum Master não planeja o trabalho, não o distribui nem reporta o desempenho das pessoas; os Developers planejam o próprio trabalho, e o Product Owner decide as prioridades. O Scrum Master orienta a equipe e remove o que a atrasa.
O Product Owner e o Scrum Master podem ser a mesma pessoa?
O Guia do Scrum não proíbe, mas raramente é uma boa ideia. O Product Owner busca mais valor; o Scrum Master protege o jeito de trabalhar da equipe. Uma pessoa que faz as duas coisas costuma perder uma dessas duas vozes.
O Kanban tem papéis?
Não. O Guia Kanban não prescreve papéis, então a equipe mantém os que já tem. O Método Kanban descreve dois papéis opcionais, o service request manager e o service delivery manager.
Antes da próxima sprint planning, faça três perguntas à equipe: quem ordena o backlog, quem remove o que nos bloqueia e quem decide como o trabalho é feito. Se as respostas não forem um nome, um nome e “todos nós”, comece por aí.