O que é Scrum?
Também conhecido como: framework Scrum, metodologia Scrum, Time Scrum, Scrum Team
Scrum é o framework ágil mais usado no mundo para gerar valor em ciclos curtos, com responsabilidades, eventos e artefatos que sustentam inspeção e adaptação constantes.
Scrum é um framework leve que ajuda pessoas, times e organizações a gerar valor por meio de soluções adaptativas para problemas complexos. Baseado no empirismo e no lean thinking, define três responsabilidades (Scrum Master, Product Owner e Desenvolvedores), cinco eventos e três artefatos, organizados em ciclos curtos chamados Sprints, sustentados pelos pilares de transparência, inspeção e adaptação.
Origem
Ken Schwaber e Jeff Sutherland apresentaram o Scrum publicamente na conferência OOPSLA de 1995, com base em experiências próprias de desenvolvimento de software nos anos anteriores. O nome vem do rúgbi, esporte em que o scrum é a formação em que o time avança o jogo unido, e foi emprestado por Hirotaka Takeuchi e Ikujiro Nonaka no artigo "The New New Product Development Game", de 1986, que descreveu times de produto trabalhando de forma integrada em vez de passar o trabalho em fases sequenciais.
Em 2001, Schwaber e Sutherland foram dois dos dezessete signatários do Manifesto Ágil. O Scrum Guide, o documento oficial e gratuito que define o framework, foi publicado pela primeira vez em 2010 e já passou por diversas revisões, incluindo 2011, 2013, 2016, 2017 e a versão atual, de 2020, que trouxe a definição mais aberta do framework e tornou a Definition of Done o compromisso do Incremento.
Em junho de 2025, Sutherland publicou com Ralph Jocham e John Coleman o Scrum Guide Expansion Pack, um complemento opcional que amplia o framework para descoberta de produto e resultado de negócio, sem substituir o guia oficial.
Fonte primária: The Scrum Guide (2020)
Na prática
Scrum organiza o trabalho em Sprints, ciclos curtos e de duração fixa (até um mês), dentro dos quais o Time Scrum planeja, executa, inspeciona e adapta. Cada Sprint gera pelo menos um Incremento de valor, utilizável e que cumpre a Definition of Done, e ele pode ser entregue a clientes antes mesmo do fim da Sprint. É essa repetição curta, sustentada pelos pilares de transparência, inspeção e adaptação, que dá ao Scrum sua previsibilidade e capacidade de responder a problemas complexos.
O que acontece quando falta
Sem um framework empírico como o Scrum, times que trabalham em problemas complexos tendem a planejar tudo antes de começar, na esperança de acertar de primeira. O plano detalhado dá uma sensação de controle que não resiste ao primeiro contato com a realidade: o mercado muda, o cliente pede outra coisa, a tecnologia não se comporta como o esperado.
Sem ciclos curtos de inspeção, os erros só aparecem no fim, quando já são caros de corrigir. Sem um Product Owner único, decisões de prioridade se arrastam em comitês. Sem eventos regulares de sincronização, o time perde a visão do todo e cada pessoa otimiza a própria parte, sem perceber o impacto no conjunto. O resultado mais comum é a entrega tardia de algo que já não resolve o problema que motivou o projeto, descoberto tarde demais para corrigir sem custo alto, e a relação entre time e negócio vira uma sucessão de prazos renegociados.
Como o Scrum funciona: papéis, eventos e artefatos
O Scrum Guide chama o Scrum de framework, não de método: ele diz o que precisa existir, não como fazer. Isso é proposital. O framework define uma estrutura mínima de papéis, eventos e artefatos, e cabe a cada time preencher os detalhes de acordo com o próprio contexto.
Os três pilares. Tudo no Scrum se apoia em empirismo: transparência (o trabalho e o progresso ficam visíveis para todos), inspeção (o time examina o trabalho e o processo com frequência) e adaptação (o time ajusta o rumo quando algo sai do esperado). Sem os três juntos, o Scrum vira teatro: os eventos acontecem no calendário, mas nada muda de verdade.
Os três papéis. O Product Owner maximiza o valor do produto e decide a ordem do Product Backlog. O Scrum Master garante que o time entenda e aplique o Scrum, remove impedimentos e atua como líder servidor. Os Desenvolvedores transformam itens do backlog em Incremento a cada Sprint. Juntos formam o Time Scrum, pequeno o suficiente para ser ágil e grande o suficiente para entregar trabalho significativo, tipicamente até dez pessoas.
Os cinco eventos. A Sprint é o contêiner de todos os outros: um ciclo de até um mês em que tudo acontece. Dentro dela, a Sprint Planning define o que será feito e por quê. A Daily Scrum sincroniza o time todos os dias em quinze minutos. A Sprint Review inspeciona o resultado com stakeholders. A Retrospectiva inspeciona o próprio processo do time. Todos os eventos têm timebox, duração máxima fixa, para criar ritmo e evitar reuniões que se arrastam.
Os três artefatos. O Product Backlog é a lista ordenada de tudo que o produto pode precisar. O Sprint Backlog é o plano do time para a Sprint atual. O Incremento é a soma de tudo que já cumpre a Definition of Done e está pronto para uso. Cada artefato carrega um compromisso: Meta do Produto no Product Backlog, Meta da Sprint no Sprint Backlog, e a própria Definition of Done no Incremento, para que a transparência tenha algo concreto para medir.
A imagem que mais ajuda a entender o Scrum é a de um ciclo que se repete: planejar, executar, inspecionar, ajustar, e recomeçar. Cada volta desse ciclo é uma Sprint, e é essa repetição curta que permite ao time aprender rápido sobre o produto e sobre o próprio trabalho.
Os cinco valores. Além dos três pilares, o Scrum Guide lista cinco valores que sustentam o dia a dia do Time Scrum: comprometimento com as metas combinadas, coragem para enfrentar problemas difíceis e dizer a verdade, foco no trabalho da Sprint, abertura sobre o trabalho e os desafios, e respeito entre as pessoas do time e com quem está fora dele. Um time pode seguir o Scrum Guide à risca e ainda assim falhar, se esses valores não estiverem presentes.
Conecte objetivos em diferentes horizontes. O Product Goal orienta o Product Backlog como objetivo de longo prazo do Time Scrum. Cada Sprint Goal dá um foco mais próximo, e o Incremento pronto fornece evidência concreta do que mudou no produto. O framework não especifica qual estratégia de produto é correta, qual arquitetura usar ou como estimar cada item. A efetividade do Scrum aparece na adaptação e no valor produzido, não apenas na presença de seus nomes no calendário.
Exemplo de um ciclo completo de Scrum
Imagine um time de sete pessoas construindo o aplicativo de uma rede de farmácias, em Sprints de duas semanas.
Segunda-feira, dia 1, de manhã: Sprint Planning. O Product Owner traz o topo do Product Backlog: permitir agendamento de vacinas pelo aplicativo. O time discute, faz perguntas, e junto com o PO define a Meta da Sprint: "clientes conseguem agendar e cancelar vacinas nas lojas próximas". Selecionam sete itens do backlog que cabem nessa meta.
Ao longo das duas semanas. Todo dia às 9h, os Desenvolvedores fazem a Daily Scrum: quinze minutos para inspecionar o progresso rumo à Meta da Sprint e ajustar o plano do dia. No terceiro dia, aparece um impedimento: a API de estoque de vacinas está fora do ar. O Scrum Master ajuda a levar o problema a quem pode resolvê-lo no time de infraestrutura, enquanto os Desenvolvedores replanejam o que dá para avançar. No oitavo dia, o agendamento já está pronto e é liberado para clientes de três lojas piloto.
Sexta-feira da segunda semana: Sprint Review. Clientes das lojas piloto usam o agendamento enquanto o time observa, e todos analisam os dados reais dos primeiros dias de uso. Vários clientes esquecem a data da vacina, e um gerente regional sugere um lembrete por SMS. O time e os stakeholders discutem o que fazer a seguir, e o Product Owner registra a ideia no Product Backlog, sem compromisso de quando será feita.
Mesma tarde: Retrospectiva. O time percebe que perdeu quase um dia inteiro por causa da API de estoque e decide criar um ambiente de testes que simula a API quando ela está fora. O time também percebe que a Daily andou virando um relatório de status para o Scrum Master e combina conduzi-la olhando o quadro a partir da Meta da Sprint e dos itens mais próximos de ficar prontos.
Segunda seguinte. Novo ciclo começa. O aprendizado da Sprint anterior, tanto sobre o produto quanto sobre o processo, já influencia o que vem a seguir. É esse encadeamento de ciclos curtos, cada um terminando em algo inspecionável, que dá ao Scrum sua previsibilidade.
Como começar a usar Scrum no seu time
Forme o Time Scrum completo
Garanta os três papéis desde o início: um Product Owner com autoridade real de priorização, um Scrum Master dedicado e os Desenvolvedores necessários para entregar um Incremento sozinhos.
Escreva a Definition of Done antes da primeira Sprint
Sem um padrão comum de qualidade, o time não consegue planejar direito nem saber quando algo está realmente pronto.
Monte um Product Backlog inicial
Não precisa estar completo. Precisa ter itens suficientes, e claros o bastante no topo, para planejar a primeira Sprint.
Escolha uma duração de Sprint e mantenha
Duas semanas é um ponto de partida comum. Trocar a duração toda hora destrói o ritmo que o Scrum tenta criar.
Rode os cinco eventos, mesmo com timebox menor no início
Um time novo pode fazer eventos mais curtos, mas nenhum deles deve ser pulado. É neles que o empirismo acontece.
Proteja a Sprint de interrupções
O Scrum Master ajuda a organização a entender que mudanças de escopo esperam a próxima Sprint, salvo emergências reais.
Use a primeira Retrospectiva para ajustar o próprio Scrum
As primeiras Sprints raramente saem perfeitas. A Retrospectiva é o espaço certo para o time adaptar como está usando o framework.
Scrum vs Kanban vs cascata (Waterfall)
| Scrum | Kanban | Cascata (Waterfall) | |
|---|---|---|---|
| Unidade de trabalho | Ciclos fixos (Sprints) | Fluxo contínuo, sem ciclos | Fases sequenciais |
| Papéis definidos | Sim: PO, Scrum Master, Desenvolvedores | Não define papéis específicos | Gerente de projeto, analistas, por fase |
| Quando muda de direção | No máximo, no início da próxima Sprint | A qualquer momento | Difícil e caro depois que uma fase termina |
| Como mede progresso | Incremento entregue por Sprint | Lead time, throughput, CFD | Percentual de conclusão do cronograma |
| Ponto forte | Ritmo previsível e feedback frequente do produto | Flexibilidade e visibilidade do fluxo | Clareza de escopo com requisitos estáveis |
| Onde funciona melhor | Problemas complexos, com incerteza sobre a solução | Trabalho de demanda variável | Trabalho com requisitos estáveis e pouca incerteza |
Scrum e Kanban não competem tanto quanto parecem: muitos times usam limites de WIP dentro da própria Sprint, misturando as duas abordagens. A cascata, por sua vez, não é errada em si, ela só assume que dá para prever tudo antes de começar, premissa que falha justamente nos problemas complexos que o Scrum foi desenhado para tratar.
Erros comuns na adoção do Scrum
- Scrum sem os pilares. Fazer os eventos no calendário sem transparência real, sem inspecionar de verdade e sem mudar nada depois, o que a comunidade chama de "Zombie Scrum".
- Product Owner fraco ou ausente. Sem autoridade de priorização, ninguém decide o que fica de fora, e o backlog vira lista de desejos.
- Scrum Master como secretário de reunião. Reduzir o papel a agendar eventos e cronometrar, sem atuar em remover impedimentos e desenvolver o time.
- Sprint Zero disfarçada. Tratar as primeiras semanas como uma fase de preparação fora do ritmo de Sprints.
- Escopo variável dentro da Sprint. Aceitar qualquer pedido novo no meio do ciclo, destruindo o compromisso com a Meta da Sprint.
- Confundir Scrum com o único jeito de ser ágil. Aplicar Scrum em contextos que pedem outra abordagem só porque é o framework mais conhecido.
- Achar que o Scrum Guide explica tudo. Estimativa, User Story, Planning Poker não estão no Scrum Guide: são práticas complementares.
- Times grandes demais. Passar de dez ou doze pessoas multiplica os canais de comunicação e torna a Daily inútil.
Visão K21
O que a gente aprendeu na prática sobre o Scrum
O Scrum Guide ficou mais enxuto, e isso foi proposital. Em "Guia do Scrum 2020: quais são as novidades?", o Rodrigo de Toledo observa que o guia encolheu 30% na revisão de 2020, de 19 para 13 páginas. O Marcos Garrido completa: a definição do Scrum ficou mais genérica, abrangendo pessoas, times e organizações.
Scrum não é um método, é um framework. No post "O que é Scrum?", o Avelino Ferreira Gomes Filho reforça essa distinção: o Scrum Guide diz o que precisa existir, mas não descreve como fazer.
A maior parte das disfunções não é do framework, é da adoção. A série sobre disfunções nos papéis de Scrum Master, Product Owner e Desenvolvedores mostra que os problemas mais comuns vêm de organizações aplicando o Scrum pela metade.
O Expansion Pack de 2025 aponta para onde o Scrum está indo. Jeff Sutherland, junto com Ralph Jocham e John Coleman, propôs cobrir todo o ciclo de vida do produto, com ênfase forte em responsabilidade profissional. É um complemento opcional, não uma nova versão do Scrum Guide oficial.
Baseado nos posts: Guia do Scrum 2020: quais são as novidades?; O que é Scrum?; Disfunções no Papel do Scrum Master; Scrum Guide Expansion Pack 2025: Tudo sobre as Novas Diretrizes do Scrum
Para se aprofundar
No blog da K21
- O que é Scrum?
Visão geral do framework a partir da definição oficial, com os três pilares e os cinco valores.
- Guia do Scrum 2020: quais são as novidades?
O que mudou entre o Scrum Guide de 2017 e o de 2020, comentado por três CSTs da K21.
- Scrum Guide Expansion Pack 2025: Tudo sobre as Novas Diretrizes do Scrum
Para onde o Scrum está caminhando, com o complemento opcional de 2025.
- Disfunções no Papel do Scrum Master
Como uma adoção malfeita distorce o framework, mesmo sem culpa do Scrum em si.
Fontes primárias
- The Scrum Guide (2020), Ken Schwaber e Jeff Sutherland (2020)
- The New New Product Development Game, Hirotaka Takeuchi e Ikujiro Nonaka (1986)
- Manifesto para Desenvolvimento Ágil de Software, Kent Beck e outros 16 signatários (2001)
Termos relacionados
Comparativos relacionados
Aprenda mais sobre os assuntos relacionados.
Scrum x Kanban
Framework para desenvolver produtos em ciclos curtos versus método de gestão de fluxo contínuo. Saiba quando usar cada um, e por que muitos times usam os dois.
CSM x CSPO
Certified ScrumMaster ou Certified Scrum Product Owner? A escolha entre cuidar do processo e do time (CSM) ou maximizar o valor do produto (CSPO).
A-CSM x A-CSPO
Segundo degrau das trilhas Scrum Master e Product Owner da Scrum Alliance: quando avançar e o que cada credencial aprofunda.
Product Owner x Product Manager
PO cuida da execução tática do backlog; PM cuida da estratégia de produto. Mesma pessoa ou pessoas diferentes? Depende da escala.
Product Owner x Project Manager
Produto contínuo versus projeto temporário: duas lógicas de organização do trabalho e como migrar de uma para a outra.
Scrum Master x Product Owner
Dois papéis complementares dentro do mesmo time Scrum. Veja o que cada um faz e por que não devem ser exercidos pela mesma pessoa.
Perguntas frequentes
O que é Scrum?
Scrum é um framework ágil que ajuda pessoas, times e organizações a gerar valor em problemas complexos, por meio de ciclos curtos chamados Sprints. Define três papéis, cinco eventos e três artefatos, todos apoiados em transparência, inspeção e adaptação frequentes.
Scrum é uma metodologia?
Não exatamente. O próprio Scrum Guide o chama de framework: ele define o que precisa existir, mas não especifica como fazer cada parte. Cada time adapta os detalhes ao próprio contexto.
Quais são os papéis do Scrum?
São três: o Product Owner, que maximiza o valor do produto; o Scrum Master, que garante a aplicação correta do framework; e os Desenvolvedores, que constroem o Incremento a cada Sprint.
Quais são os eventos do Scrum?
São cinco: a Sprint, a Sprint Planning, a Daily Scrum, a Sprint Review e a Retrospectiva. Todos têm duração máxima fixa, o timebox.
Quem criou o Scrum?
Ken Schwaber e Jeff Sutherland apresentaram o Scrum em 1995, na conferência OOPSLA. O nome vem de um termo do rúgbi, usado antes por Takeuchi e Nonaka em um artigo de 1986.
Qual a diferença entre Scrum e Kanban?
O Scrum organiza o trabalho em ciclos fixos, as Sprints. O Kanban gerencia um fluxo contínuo, sem ciclos obrigatórios. Muitos times combinam elementos dos dois, o que costuma ser chamado de Scrumban.
