Framework Scrum: Papéis, Eventos e Artefatos Explicados (Com Exemplos)

A maioria das pessoas aprende o Scrum da forma errada. Tratam-no como uma lista de reuniões a agendar e papéis a atribuir, realizam alguns Sprints e depois se perguntam por que o time ainda entrega devagar e o Product Backlog nunca diminui. O framework Scrum não é uma metodologia que você implementa uma vez e esquece. É um ciclo de feedback que você adapta a cada Sprint, e essa distinção importa muito.

O Scrum é leve por design. Ele oferece estrutura suficiente para identificar problemas rapidamente e corrigi-los antes que se agravem. Os times que extraem valor real dele são os que levam o princípio de inspecionar e adaptar a sério, não aqueles que simplesmente renomeiam seus Stand-ups de "Daily Scrum".

O que é o framework Scrum?

O Scrum é um framework Agile leve para entregar produtos complexos por meio de iterações curtas e com tempo definido chamadas Sprints. Ele não prescreve práticas de engenharia ou ferramentas específicas. Em vez disso, define um conjunto mínimo de papéis, eventos e artefatos projetados para criar transparência, permitir inspeção frequente e tornar a adaptação ágil.

Jeff Sutherland e Ken Schwaber desenvolveram o Scrum no início dos anos 1990, com base em conceitos da manufatura Lean e do controle de processos empíricos. Eles o apresentaram publicamente pela primeira vez na conferência OOPSLA em 1995. O primeiro Scrum Guide formal foi publicado em 2010. A versão mais recente, o Scrum Guide 2020, simplificou ainda mais o framework, removendo elementos prescritivos e aprimorando o foco nos três pilares do empirismo: transparência, inspeção e adaptação.

O pensamento Lean permeia tudo isso. Os times Scrum eliminam desperdício trabalhando em ciclos curtos, obtendo feedback real de software funcionando e interrompendo trabalho que não avança o produto em direção ao seu objetivo.

Dados-Chave

• Sutherland e Schwaber apresentaram o Scrum pela primeira vez na conferência OOPSLA em 1995, introduzindo o conceito de iterações com tempo definido e papéis definidos.
• O Scrum Guide 2020 (disponível em scrumguides.org) é a fonte canônica. Ele removeu o termo "Time de Desenvolvimento" e simplificou significativamente o framework em comparação com versões anteriores.
• De acordo com o 17º Relatório State of Agile (Digital.ai, 2023), o Scrum continua sendo a abordagem Agile mais utilizada, com 87% das equipes Agile usando Scrum ou um híbrido de Scrum.

O ciclo do Scrum visualizado

O ciclo do Scrum é um loop empírico. Começa com o Product Backlog, uma lista ordenada de tudo que o time pode trabalhar. Cada ciclo começa com o Sprint Planning, onde o time seleciona itens do Product Backlog e cria um Sprint Backlog, o trabalho específico que será concluído no Sprint seguinte.

O Sprint em si dura de uma a quatro semanas. Durante ele, o time realiza um Daily Scrum todos os dias: uma reunião de coordenação de 15 minutos na qual os Desenvolvedores inspecionam o progresso e replanejarão seu trabalho para as próximas 24 horas.

Ao final do Sprint, o time entrega um Increment funcionando, algo que atende à Definition of Done e que, em princípio, poderia ser lançado. O Sprint Review é uma sessão informal na qual o time e as partes interessadas inspecionam o Increment e discutem os próximos passos. Depois vem a Sprint Retrospective, na qual o time se examina: como trabalharam, o que melhorar e o que levar para o próximo Sprint.

E então o ciclo se repete. Product Backlog, Sprint Planning, Sprint, Increment, Review, Retro, Product Backlog. O loop é o framework. Ele é curto para que os erros sejam baratos e o aprendizado seja rápido.

Os 3 papéis do Scrum (o Scrum Team)

O Scrum Guide 2020 removeu o conceito de sub-times. Existe um único Scrum Team, sem hierarquia, e três responsabilidades dentro dele.

Product Owner

O Product Owner é responsável por maximizar o valor do produto. Ele é dono do Product Backlog, criando-o, ordenando-o e garantindo que os Desenvolvedores entendam o que está nele. Uma restrição crítica do Scrum Guide: o Product Owner é uma pessoa, não um comitê. As decisões sobre o que será construído precisam vir de uma única voz.

Na prática, o Product Owner trabalha na interseção entre a estratégia de negócio e o trabalho de desenvolvimento. Ele está constantemente tomando decisões: qual funcionalidade vale mais a pena construir agora, qual necessidade do usuário priorizar, qual item do Backlog cortar. Um Product Owner fraco, que não consegue tomar essas decisões rapidamente, cria um gargalo que todo o Scrum Team sentirá a cada Sprint.

O Product Owner não é um intermediário. Quando as partes interessadas querem algo, elas trabalham com o Product Owner, não ao redor dele. Se a organização não respeita esse limite, o Scrum não funcionará bem.

Scrum Master

O Scrum Master serve ao Scrum Team e à organização como um todo. Ele é responsável pela eficácia do time: ajudar os Desenvolvedores a trabalhar bem juntos, auxiliar o Product Owner com técnicas de Backlog, remover impedimentos e orientar a organização na adoção do Scrum.

O Scrum Master não é um gerente de projeto. Ele não atribui tarefas, controla horas nem reporta a executivos sobre a produção do time. Seu papel é mais próximo ao de um coach e líder servidor. Ele protege o time de distrações, facilita eventos e reage quando alguém (incluindo a alta liderança) tenta contornar o framework de maneiras que prejudicam o time.

Um erro comum é tratar o papel de Scrum Master como parcial, algo que um desenvolvedor cuida junto com seu trabalho regular no Sprint. Isso pode funcionar para times experientes, mas um time novo que está adotando o Scrum pela primeira vez se beneficia de um Scrum Master dedicado, capaz de observar o sistema de verdade.

Desenvolvedores

Os Desenvolvedores são as pessoas que criam o Increment a cada Sprint. O Scrum Guide 2020 mudou o nome de "Time de Desenvolvimento" para "Desenvolvedores" para sinalizar que a responsabilidade pertence a todos que executam o trabalho, não a um sub-time.

Os Desenvolvedores são multifuncionais. O Scrum Team como um todo possui todas as habilidades necessárias para entregar um incremento de produto funcionando. Isso pode incluir designers, engenheiros, testers e redatores no mesmo time, mas o Scrum Guide não exige nenhum conjunto específico de habilidades.

Os Desenvolvedores são donos do Sprint Backlog e gerenciam seu próprio trabalho. Ninguém fora do Scrum Team diz como eles devem fazer seus trabalhos nem atribui tarefas a indivíduos. Eles decidem como transformar os itens do Sprint Backlog no Increment.

Os 5 eventos do Scrum

Cada evento do Scrum tem tempo definido e é proposital. O tempo definido não se trata apenas de eficiência. Ele cria um ritmo previsível e força decisões. Veja todos os cinco, com suas durações máximas oficiais.

Sprint

O Sprint é o contêiner de todos os outros eventos do Scrum. É uma iteração de duração fixa de um mês ou menos. Durante um Sprint, nenhuma mudança é feita que coloque em risco a meta do Sprint, o escopo pode ser esclarecido à medida que o time aprende mais, e o Sprint não é cancelado a menos que a meta do Sprint se torne obsoleta.

A duração consistente de um Sprint cria um ritmo. O time sabe quando é o Planning, quando é o Review e quando chega a próxima oportunidade de entregar. A maioria dos times usa Sprints de duas semanas, embora o tamanho certo dependa da tolerância ao risco, da frequência com que o produto muda e do quanto de feedback o time precisa.

Sprint Planning

O Sprint Planning inicia o Sprint e responde a duas perguntas: o que pode ser entregue neste Sprint e como o trabalho será feito? O Product Owner apresenta o topo do Product Backlog e o time seleciona o trabalho que acredita poder concluir.

O resultado é a meta do Sprint, um único objetivo que dá coesão ao Sprint, e o Sprint Backlog, os itens específicos selecionados mais um plano para entregá-los.

Limite de tempo: até 8 horas para um Sprint de um mês. Sprints mais curtos usam proporcionalmente menos tempo.

Daily Scrum

O Daily Scrum é um evento de 15 minutos para os Desenvolvedores inspecionarem o progresso em direção à meta do Sprint e adaptarem seu plano para as próximas 24 horas. Não é um relatório de status para o Scrum Master. É coordenação entre Desenvolvedores.

O Scrum Guide 2020 removeu as três perguntas prescritas (o que fiz ontem, o que farei hoje, há algum impedimento) e deu às equipes flexibilidade sobre como conduzir o evento, desde que o propósito seja cumprido. O objetivo é que os Desenvolvedores saiam sabendo o que cada um está fazendo e onde estão os impedimentos.

Sprint Review

O Sprint Review é uma inspeção do Increment e uma adaptação do Product Backlog. O Scrum Team e as partes interessadas analisam o que foi realizado, discutem o que mudou no mercado ou no negócio e alinham os próximos passos.

Não é uma demo, embora demos frequentemente aconteçam nele. A distinção importa: uma demo é uma apresentação; um Sprint Review é uma sessão de trabalho. As partes interessadas não são plateia, são participantes.

Limite de tempo: até 4 horas para um Sprint de um mês.

Sprint Retrospective

A Sprint Retrospective é onde o Scrum Team se examina. O que funcionou bem, o que não funcionou e uma ou duas coisas que farão de forma diferente no próximo Sprint? O resultado é um plano de melhoria concreto com o qual o time se compromete a agir.

Este evento é o motor da melhoria contínua no Scrum. Times que pulam as retrospectivas ou as tratam como formalidade param de melhorar. O valor se acumula ao longo do tempo, então os times com as melhores práticas de retrospectiva tendem a ser os times de melhor desempenho ao longo de um ano ou mais.

Limite de tempo: até 3 horas para um Sprint de um mês.

Os 3 artefatos do Scrum e seus compromissos

O Scrum Guide 2020 associou cada artefato a um compromisso, uma meta mensurável que dá direção ao artefato e contra a qual o progresso pode ser inspecionado.

Product Backlog (compromisso: Product Goal)

O Product Backlog é uma lista ordenada e dinâmica de tudo que pode ser feito para melhorar o produto. Ele nunca está completo. Novos itens são adicionados, os antigos são removidos e as prioridades mudam à medida que o time aprende.

O compromisso do Product Backlog é o Product Goal: o objetivo de longo prazo que o Scrum Team está perseguindo. Cada Sprint deve aproximar o produto do Product Goal, e o Product Backlog existe para descrever o caminho até lá.

O Product Owner é dono do Product Backlog e é responsável por sua ordenação e clareza.

Sprint Backlog (compromisso: meta do Sprint)

O Sprint Backlog é o conjunto de itens do Product Backlog selecionados para o Sprint, mais o plano para entregá-los, mais a meta do Sprint. É uma imagem em tempo real do trabalho que os Desenvolvedores planejam realizar neste Sprint.

O compromisso é a meta do Sprint: um único objetivo que dá propósito ao Sprint. Se surgir novo trabalho durante o Sprint, os Desenvolvedores o adicionam ao Sprint Backlog somente se não ameaçar a meta do Sprint.

Increment (compromisso: Definition of Done)

Um Increment é um passo concreto em direção ao Product Goal. Cada Sprint deve produzir pelo menos um Increment. Ele deve ser utilizável e atender aos padrões do time.

O compromisso é a Definition of Done (DoD): um entendimento compartilhado do que significa "pronto". Se um item não atende à Definition of Done, não faz parte do Increment. A DoD cria transparência e consistência. Não é uma lista de verificação por item; é um padrão de qualidade que se aplica a todos os Increments.

Visão geral: papéis + eventos + artefatos

Os 11 elementos são tudo que o Scrum prescreve. Esse é o framework completo. Qualquer coisa além desses 11 elementos é uma prática complementar (como desenvolvimento orientado a testes ou mapeamento de histórias de usuário) ou uma adição organizacional que você gerencia separadamente.

Uma cadência típica de Sprint de 2 semanas

Veja como um Sprint padrão de duas semanas funciona na prática, dia a dia.

Dia 1: Sprint Planning. O time se reúne, revisa o topo do Product Backlog com o Product Owner, define a meta do Sprint e constrói o Sprint Backlog. Para um Sprint de duas semanas, o Planning geralmente dura de 2 a 4 horas.

Dias 1 a 10: Desenvolvimento. Todos os dias, inclusive o Dia 1, o time realiza um Daily Scrum de 15 minutos. Os Desenvolvedores se coordenam, identificam impedimentos e replaneiam conforme necessário. O Scrum Master remove os impedimentos. O Product Owner está disponível para esclarecimentos.

Manhã do Dia 10: Sprint Review. O time apresenta o Increment para as partes interessadas, recebe feedback e atualiza o Product Backlog. Normalmente dura de 1 a 2 horas para um Sprint de duas semanas.

Tarde do Dia 10: Sprint Retrospective. O Scrum Team olha para dentro. O que funcionou, o que não funcionou, que mudanças tentar no próximo Sprint. Até 1,5 hora.

Dia 11: Novo Sprint começa. Mesma estrutura, mesma cadência, com uma ou duas melhorias trazidas da retro.

A consistência é o ponto central. Quando cada Sprint tem a mesma forma, o custo de coordenação diminui e o time pode se concentrar no trabalho real. Consulte planejamento de projetos para saber como conectar as cadências de Sprint a cronogramas de projeto mais amplos.

Scrum vs Kanban vs Waterfall

O Scrum é frequentemente comparado ao Kanban e à metodologia Waterfall tradicional. As diferenças vão além de ter ou não Sprints ou um quadro.

Em resumo: use o Scrum quando estiver construindo algo complexo e os requisitos mudarão à medida que você aprende. Use o Kanban quando o trabalho chegar continuamente e você precisar otimizar o fluxo em vez da iteração. Use o Waterfall quando o escopo for fixo, o risco de mudança for baixo e você precisar de um plano completo antecipadamente (comum em construção civil, setores com forte regulação ou contratos de preço fixo).

Muitos times usam um híbrido Scrum/Kanban: cadência de Sprint para trabalho de desenvolvimento planejado, quadro Kanban para bugs e solicitações não planejadas. Isso é válido, desde que o time tenha clareza sobre qual sistema rege qual trabalho.

Para ferramentas de cronograma estruturado que complementam o Scrum, consulte estrutura analítica do projeto, método do caminho crítico, gráficos de Gantt e gráficos PERT.

Erros comuns que quebram o Scrum

A maioria das falhas do Scrum não são falhas do framework. São falhas de implementação. Estes são os mais comuns:

• Pular a Sprint Retrospective. Este é o evento em que o Scrum se acumula. Times que pulam ficam no mesmo nível de disfunção indefinidamente. Se o tempo está curto, encurte a retro, mas não a elimine.
• Tratar o Scrum Master como gerente de projeto. Atribuir tarefas, reportar Velocity para a liderança e gerenciar cronogramas são funções de PM. Um Scrum Master fazendo essas tarefas não está fazendo trabalho de Scrum Master. Ambos os papéis sofrem.
• Não ter um Product Owner de verdade. Um Product Owner que não consegue tomar decisões de priorização, precisa de aprovação de três comitês ou muda a meta do Sprint no meio do caminho quebra a capacidade do time de planejar e entregar.
• Permitir que as partes interessadas contornem o Product Owner. Desenvolvedores recebendo solicitações de funcionalidades diretamente de executivos ou clientes é um sinal de que a autoridade do Product Owner não é respeitada. Corrija a cultura organizacional, não o framework.
• Executar Sprints sem meta do Sprint. Um Sprint que é apenas uma lista de tarefas não tem objetivo unificador. O time não consegue tomar boas decisões de troca quando surgem novas informações, pois não há nada a proteger.
• Tratar o Scrum como a solução completa. O Scrum não inclui práticas de engenharia. Os times também precisam de automação de testes, integração contínua e padrões claros de qualidade (a Definition of Done) para realmente entregar incrementos funcionando. Sem isso, o Sprint Review se torna um desfile de funcionalidades incompletas.

Perguntas frequentes

O Scrum é o mesmo que Agile?

Não. O Agile é um conjunto de valores e princípios, descritos no Manifesto Agile (2001). O Scrum é um framework para implementar esses princípios. Você pode ser Agile sem usar o Scrum, e pode executar o Scrum de forma ruim, contradizendo os valores Agile. Pense no Agile como a filosofia e no Scrum como uma forma estruturada de praticá-la. Outros frameworks Agile incluem Kanban, Extreme Programming (XP) e SAFe (Scaled Agile Framework).

O Scrum funciona sem um Scrum Master?

Tecnicamente, o Scrum exige um Scrum Master. Na prática, times maduros às vezes operam sem um dedicado, distribuindo as responsabilidades de coaching e facilitação entre os membros do time. Mas times novos no Scrum geralmente precisam de um Scrum Master que proteja ativamente o framework, oriente o time e remova impedimentos organizacionais. Sem esse papel, os times tendem a retornar aos hábitos antigos: os Stand-ups viram reuniões de status, as retros são puladas e o Product Owner perde a autoridade sobre o Backlog.

Qual deve ser a duração de um Sprint?

O Scrum Guide 2020 diz um mês ou menos, com a maioria dos times escolhendo de uma a quatro semanas. Os Sprints de duas semanas são os mais comuns na prática. O tamanho certo depende da estabilidade dos requisitos, da frequência com que o time precisa de feedback externo e do quanto de cerimônias o time consegue absorver. Sprints mais curtos significam feedback mais rápido, mas mais cerimônias em relação ao tempo de desenvolvimento. Sprints mais longos reduzem o custo das cerimônias, mas atrasam o feedback. Comece com duas semanas e ajuste com base no que aprender.

O que foi removido no Scrum Guide 2020?

A revisão de 2020 removeu várias coisas que tinham se acumulado em versões anteriores. As três perguntas prescritas do Daily Scrum ("o que fiz ontem, o que farei hoje, há algum impedimento?") foram removidas em favor de formatos flexíveis. O termo "Time de Desenvolvimento" foi substituído por "Desenvolvedores". O conceito de Chief Product Owner e Sprint 0 foram eliminados. O papel do Scrum Master como "líder servidor" foi reformulado para simplesmente "verdadeiro líder". O guia de 2020 também adicionou os três compromissos dos artefatos (Product Goal, meta do Sprint, Definition of Done) pela primeira vez, que foram acréscimos, não remoções.

O Scrum continuará evoluindo. Esse é o ponto. O próprio framework pratica o que prega: inspecione, adapte e entregue uma versão mais enxuta.

Para times que desejam usar uma matriz RACI junto com seus papéis do Scrum, observe que o RACI funciona bem para mapear direitos de decisão entre as partes interessadas, enquanto os papéis do Scrum definem responsabilidades dentro do time. Os dois frameworks se complementam em vez de conflitar.