O que é Scrum? Guia completo para quem está começando

Se você já ouviu falar em Sprint, Daily, backlog ou Scrum Master e ficou com a sensação de que todo mundo entende menos você, este guia é o ponto de partida. A ideia aqui não é decorar termos, e sim entender a lógica que faz o Scrum funcionar, para que cada palavra nova tenha um lugar claro na sua cabeça.

Vamos responder, em ordem: o que é Scrum em uma frase, de onde ele veio, qual problema ele resolve, como funcionam papéis, eventos e artefatos, como é um Sprint na prática, quais são os erros mais comuns e quando o Scrum não é a melhor escolha. No fim, você terá base suficiente para acompanhar uma conversa de time ágil e decidir se vale aprofundar.

O que é Scrum, em uma frase

Scrum é um framework leve para organizar o trabalho de equipes que lidam com problemas complexos, entregando valor em ciclos curtos e ajustando o rumo a partir do que aprendem em cada ciclo.

Três palavras dessa frase merecem atenção:

• Framework: Scrum não é uma metodologia completa com passo a passo para tudo. É uma estrutura mínima de papéis, eventos e artefatos. O que acontece dentro dessa estrutura (as técnicas de estimativa, o formato das histórias, as ferramentas) é escolha do time.
• Complexo: Scrum foi pensado para trabalho em que não dá para saber tudo de antemão. Desenvolver um produto novo, lançar um serviço, reorganizar um processo. Se o trabalho é repetitivo e previsível, outras abordagens podem servir melhor.
• Ciclos curtos: em vez de planejar meses de trabalho e só mostrar resultado no fim, o time entrega algo utilizável a cada ciclo, chamado Sprint, e usa esse resultado para decidir o próximo passo.

É comum ouvir "metodologia Scrum". Na prática, as duas principais referências do mercado preferem a palavra framework, justamente para deixar claro que Scrum define o essencial e deixa espaço para o contexto de cada equipe.

De onde o Scrum veio

O nome vem do rúgbi. Em 1986, os pesquisadores Hirotaka Takeuchi e Ikujiro Nonaka publicaram na Harvard Business Review o artigo "The New New Product Development Game", em que comparavam equipes de desenvolvimento de produto de alto desempenho a um time de rúgbi avançando junto com a bola, em vez de uma corrida de revezamento em que cada área passa o bastão para a próxima.

No início dos anos 1990, Ken Schwaber e Jeff Sutherland aplicaram essas ideias ao desenvolvimento de software e apresentaram o Scrum formalmente em 1995. Em 2001, os dois estiveram entre os signatários do Manifesto Ágil, o documento que consolidou os valores e princípios do que hoje chamamos de agilidade.

Em 2010, Schwaber e Sutherland publicaram a primeira versão do Scrum Guide, um documento curto e gratuito que define as regras do framework. A versão vigente é de novembro de 2020. Paralelamente, a SCRUMstudy publica o SBOK Guide (Scrum Body of Knowledge), uma referência mais extensa, voltada à aplicação do Scrum em projetos e organizações. Falaremos sobre a diferença entre os dois mais adiante.

Apesar da origem no software, Scrum hoje é usado em marketing, educação, RH, engenharia, operações e qualquer área em que o trabalho tem incerteza e precisa de entregas frequentes.

Que problema o Scrum resolve

Imagine um projeto planejado em detalhe por seis meses antes de começar. No mês cinco, o cliente vê o resultado pela primeira vez e percebe que precisava de outra coisa. Ou o mercado mudou. Ou a premissa técnica do plano não se confirmou. Todo o esforço foi gasto antes de alguém descobrir que o caminho estava errado.

Esse é o problema central: em trabalho complexo, o plano inicial quase sempre está parcialmente errado, e a pergunta é quanto tempo e dinheiro você gasta até descobrir isso.

Scrum ataca o problema encurtando o intervalo entre fazer e aprender. A cada Sprint, que dura no máximo um mês e, na prática, costuma durar de uma a quatro semanas, o time entrega um incremento que pode ser inspecionado por quem vai usar ou pagar pelo resultado. O risco de seguir na direção errada fica limitado ao tamanho de um Sprint.

A base: empirismo e pensamento enxuto

O Scrum Guide apoia o framework em duas ideias. A primeira é o empirismo: conhecimento vem da experiência, e decisões devem ser tomadas com base no que é observado. A segunda é o pensamento enxuto (lean): reduzir desperdício e focar no essencial.

O empirismo se sustenta em três pilares:

1. Transparência: o trabalho e o progresso precisam estar visíveis para quem faz e para quem recebe. Se ninguém vê o backlog, ninguém consegue discutir prioridade.
2. Inspeção: o time examina com frequência os artefatos e o progresso em direção às metas, para detectar desvios cedo.
3. Adaptação: se a inspeção mostra que algo está fora do aceitável, o processo ou o produto deve ser ajustado o quanto antes.

Repare que os três dependem um do outro. Inspecionar algo que não é transparente gera conclusões erradas. Inspecionar sem disposição para adaptar é só cerimônia. Boa parte dos problemas de times que "fazem Scrum mas não funciona" está em um desses pilares quebrado.

Os cinco valores do Scrum

O Scrum Guide também define cinco valores que dão sustentação ao trabalho em equipe: compromisso, foco, abertura, respeito e coragem. Eles parecem genéricos, mas têm consequências práticas. Coragem, por exemplo, é dizer na Sprint Review que a funcionalidade não ficou boa, em vez de mostrar um resultado maquiado. Abertura é admitir um impedimento na Daily em vez de esperar que ele se resolva sozinho.

Os papéis: quem faz o quê

No Scrum Guide de 2020, o Scrum Team é formado por três responsabilidades:

• Product Owner: responsável por maximizar o valor do produto. Gerencia o Product Backlog, define e comunica a meta do produto e decide a ordem do que será feito.
• Scrum Master: responsável pela eficácia do time. Ajuda todos a entender e aplicar o Scrum, remove impedimentos e trabalha com a organização para que o ambiente favoreça o trabalho.
• Developers: as pessoas que constroem o incremento a cada Sprint. "Developers" aqui não significa só programadores; inclui qualquer especialista necessário para a entrega, como designers, analistas, redatores ou engenheiros.

O Scrum Guide indica que o time costuma ter 10 pessoas ou menos, sem hierarquias internas nem subtimes. O SBOK Guide usa uma nomenclatura um pouco diferente, chamando os desenvolvedores de Scrum Team e acrescentando papéis não essenciais, como stakeholders e o Scrum Guidance Body. Se quiser entender cada papel em profundidade, veja nosso guia sobre os papéis do Scrum.

Os eventos: o ritmo do trabalho

Scrum organiza o tempo em eventos com duração máxima definida, o chamado timebox. Os valores abaixo são os do Scrum Guide para um Sprint de um mês; para Sprints mais curtos, os eventos costumam ser proporcionalmente menores.

Um ponto que confunde iniciantes: a Daily não é reunião de status para o chefe. É um momento curto dos próprios Developers para responder "estamos indo na direção da meta do Sprint? O que precisa mudar hoje?". Quando vira prestação de contas individual, perde a função.

Outro ponto: o refinamento do backlog não é um evento formal no Scrum Guide, mas é uma atividade contínua em que o time detalha, estima e reorganiza os itens futuros. Muitas equipes reservam um horário fixo para isso.

Os artefatos e seus compromissos

Scrum tem três artefatos, e o Scrum Guide de 2020 associou a cada um deles um compromisso que dá foco e permite medir progresso:

• Product Backlog → Meta do Produto (Product Goal). O backlog é a lista ordenada e emergente do que é necessário para melhorar o produto. A meta do produto é o objetivo de longo prazo que dá sentido a essa lista.
• Sprint Backlog → Meta do Sprint (Sprint Goal). É o conjunto de itens selecionados para o Sprint mais o plano para entregá-los. A meta do Sprint é o único objetivo do ciclo e dá flexibilidade sobre o trabalho exato.
• Incremento → Definição de Pronto (Definition of Done). O incremento é o resultado utilizável do Sprint. A Definition of Done é a descrição formal do estado em que ele precisa estar para ser considerado pronto.

Existe também a Definition of Ready, um acordo sobre quando um item está claro o bastante para entrar em um Sprint. Ela não faz parte do Scrum Guide, mas é uma prática muito usada. Explicamos em detalhe no artigo Definition of Ready: o checklist que toda Sprint deveria ter.

Como é um Sprint na prática

Vamos a um exemplo ilustrativo e fictício, para tornar tudo concreto. Uma pequena empresa de treinamentos quer reduzir o tempo que leva para confirmar inscrições de alunos. Hoje tudo é feito por e-mail e planilha.

1. Antes do Sprint: a Product Owner organizou o backlog. No topo estão itens como "formulário de inscrição com campos obrigatórios", "confirmação automática por e-mail" e "painel com inscrições pendentes".
2. Sprint Planning (segunda-feira): o time define a meta do Sprint de duas semanas: "o aluno recebe confirmação de inscrição sem intervenção manual". Seleciona os dois primeiros itens e quebra o trabalho em tarefas.
3. Dailies (todos os dias, 15 minutos): na quarta, alguém percebe que o provedor de e-mail exige uma configuração de domínio que depende da TI. O Scrum Master assume a conversa com a TI para destravar.
4. Sprint Review (última sexta): o time mostra o formulário e a confirmação funcionando para a coordenação. A coordenação pede que a confirmação inclua o endereço da sala. O pedido vira item novo no backlog.
5. Retrospectiva (logo depois): o time percebe que perdeu dois dias esperando a TI. Decide, para o próximo Sprint, mapear dependências externas já no planejamento.

Observe o ciclo: em duas semanas existe algo utilizável, a coordenação deu um retorno que ninguém tinha previsto e o time melhorou o próprio processo. Esse é o empirismo funcionando.

Scrum Guide e SBOK: duas referências, uma lógica

Quem começa a estudar costuma encontrar as duas referências e se perguntar qual está "certa". As duas compartilham a mesma base, com propósitos diferentes:

• Scrum Guide: curto, com cerca de 13 páginas, focado nas regras mínimas do framework. É a base das certificações da Scrum.org e da Scrum Alliance.
• SBOK Guide: mais extenso, organiza o Scrum em princípios, aspectos e processos, com orientação para aplicar em projetos, programas e portfólios. É a base das certificações da SCRUMstudy, como SFC, SMC e SPOC.

O SBOK descreve seis princípios: controle empírico de processos, auto-organização, colaboração, priorização baseada em valor, timeboxing e desenvolvimento iterativo. Se você comparar com o que vimos acima, vai reconhecer as mesmas ideias com outra organização. Para entender como as certificações de cada organização se diferenciam, leia SFC, SMC, PSM: as certificações de Scrum e as diferenças entre elas.

Scrum, Kanban e gestão tradicional

Não existe abordagem superior em todos os casos. Muitas equipes combinam elementos, por exemplo usando um quadro Kanban para visualizar o trabalho dentro de um Sprint.

Erros comuns de quem está começando

• Tratar Scrum como lista de reuniões. Fazer todos os eventos sem transparência, inspeção e adaptação gera o famoso "Scrum de fachada".
• Sprint sem meta. Sem meta, o Sprint vira uma pilha de tarefas desconectadas e ninguém sabe o que priorizar quando surge um imprevisto.
• Product Owner sem autoridade. Se toda decisão de prioridade precisa subir três níveis, o backlog fica parado e o time perde ritmo.
• Scrum Master como secretário. Marcar reuniões e atualizar quadro é o mínimo; o papel envolve remover impedimentos e melhorar o funcionamento do time.
• Incremento que não está pronto. Entregar algo "quase pronto" esconde trabalho acumulado e compromete a previsibilidade. Por isso a Definition of Done importa.
• Mudar a meta no meio do Sprint sem critério. O backlog pode mudar a qualquer momento; o Sprint em andamento deve ser protegido para que o time consiga terminar o que começou.

Quando o Scrum não é a melhor escolha

Scrum resolve um tipo específico de problema. Ele tende a não ser a melhor opção quando:

• o trabalho é repetitivo, com pouca incerteza, como um processo operacional estável;
• as demandas chegam de forma imprevisível e precisam ser atendidas no mesmo dia, como uma central de suporte, caso em que um fluxo contínuo costuma funcionar melhor;
• não existe ninguém com autoridade real para priorizar, e a organização não está disposta a criar esse papel;
• o resultado só pode ser entregue de uma vez, sem nenhuma forma de entrega parcial com valor.

Reconhecer esses limites é sinal de maturidade, não de desconfiança do framework.

Como começar a estudar Scrum

Um caminho prático, em quatro passos:

1. Leia o Scrum Guide. É gratuito, curto e está disponível em português no site oficial (scrumguides.org). Leia duas vezes: a primeira para entender a estrutura, a segunda para prestar atenção nas palavras exatas.
2. Faça um curso introdutório com exame. A Scrum Fundamentals Certified (SFC), da SCRUMstudy, é gratuita e cobre os fundamentos com base no SBOK. Explicamos como ela funciona em Como funciona o exame da SFC.
3. Observe um time real. Se a sua empresa usa Scrum, peça para acompanhar uma Sprint Review ou uma retrospectiva. Ver o framework em ação acelera muito o aprendizado.
4. Decida o aprofundamento. Depois dos fundamentos, escolha um papel: Scrum Master, Product Owner ou membro da equipe. Cada um tem certificações específicas.

Perguntas frequentes sobre Scrum

Scrum é só para software?

Não. Nasceu em desenvolvimento de produto e ficou famoso no software, mas é aplicado em qualquer trabalho complexo que permita entregas incrementais.

Qual a duração ideal de um Sprint?

O Scrum Guide define o máximo de um mês. Sprints de duas semanas são comuns porque equilibram tempo para entregar algo relevante e frequência de retorno. O importante é manter a duração consistente.

Preciso de certificação para trabalhar com Scrum?

Não é obrigatória por lei nem pelo framework. Ela ajuda a estruturar o estudo e pode pesar em processos seletivos, mas não substitui prática. Discutimos isso em Vale a pena fazer certificação Scrum Master?

Scrum e agilidade são a mesma coisa?

Não. Agilidade é o conjunto de valores e princípios do Manifesto Ágil. Scrum é um dos frameworks que colocam esses valores em prática, assim como Kanban, XP e outros.

Qual a diferença entre Scrum Master e gerente de projetos?

O gerente de projetos tradicional costuma planejar, distribuir tarefas e responder pelo cronograma. O Scrum Master não distribui tarefas: ajuda o time a se auto-organizar e remove impedimentos. Veja mais em Scrum Master: o que faz e como se tornar um.

Resumo

Scrum é um framework para trabalho complexo, apoiado em transparência, inspeção e adaptação. Três responsabilidades (Product Owner, Scrum Master e Developers), cinco eventos (Sprint, Planning, Daily, Review e Retrospectiva) e três artefatos com seus compromissos (Product Backlog e meta do produto, Sprint Backlog e meta do Sprint, Incremento e Definition of Done). O valor não está em seguir o ritual, e sim em encurtar o tempo entre fazer, mostrar e aprender.

Se esse primeiro contato despertou interesse, o próximo passo natural é estudar os fundamentos de forma estruturada e testar seu entendimento em um exame.