O que é Scrum e como funciona o framework na prática
Se você precisa entender o que é Scrum para começar num projeto novo, conversar com um time de desenvolvimento ou se preparar para uma certificação, a definição oficial cabe numa frase: Scrum é um framework leve que ajuda pessoas, times e organizações a gerar valor por meio de soluções adaptativas para problemas complexos. Essa é a redação do Guia do Scrum, o documento de Ken Schwaber e Jeff Sutherland que define o framework, na versão de novembro de 2020.
A frase é curta, mas tem três palavras que explicam quase tudo. "Framework" quer dizer que o Scrum dá uma estrutura mínima, e não um passo a passo completo. "Adaptativas" quer dizer que o plano muda conforme o time aprende. E "complexos" delimita onde ele funciona: trabalho em que não dá para saber tudo no início.
Muita coisa que circula como "regra do Scrum" (as três perguntas da reunião diária, pontos de história, o cargo de gerente do time) não está no Guia ou saiu dele em 2020. Por isso, tudo o que vem abaixo segue o texto oficial, que é gratuito e tem tradução para o português em scrumguides.org.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é Scrum, segundo o Guia do Scrum
O Guia resume o funcionamento em um ciclo de quatro movimentos, sustentado por um Scrum Master que promove o ambiente certo:
- O Product Owner ordena o trabalho de um problema complexo num Product Backlog.
- O Scrum Team transforma uma parte desse trabalho num incremento de valor durante uma Sprint.
- O Scrum Team e os stakeholders inspecionam o resultado e ajustam o rumo para a próxima Sprint.
- Repete.
Duas características diferenciam o Scrum de uma "metodologia" no sentido tradicional. A primeira: ele é propositalmente incompleto. O Guia define apenas as partes necessárias e deixa para o time escolher técnicas como histórias de usuário, estimativa em pontos ou quadro de tarefas. Nada disso é obrigatório no Scrum. A segunda: o framework é imutável como conjunto. O Guia diz que é possível implementar só partes dele, mas o resultado não é Scrum.
Sobre a origem: o nome vem do rugby, em que o scrum é a formação em que o time se agrupa para avançar com a bola. A imagem foi usada por Hirotaka Takeuchi e Ikujiro Nonaka num artigo da Harvard Business Review de 1986 sobre desenvolvimento de novos produtos. Schwaber e Sutherland desenvolveram o framework no início dos anos 1990 e o apresentaram juntos na conferência OOPSLA, em 1995. A primeira versão do Guia do Scrum é de 2010.
A base do Scrum: empirismo, pilares e valores
O Scrum se apoia no empirismo (o conhecimento vem da experiência e as decisões se baseiam no que é observado) e no lean thinking (reduzir desperdício e focar no essencial). Na prática, isso se traduz em três pilares:
- Transparência: o trabalho e o processo ficam visíveis para quem faz e para quem recebe. Um backlog que só o gerente entende não é transparente.
- Inspeção: os artefatos e o progresso rumo às metas são examinados com frequência, e os eventos existem para isso.
- Adaptação: quando algo sai dos limites aceitáveis, o processo ou o produto é ajustado o quanto antes.
Os três dependem um do outro. Inspecionar sem transparência engana; inspecionar sem adaptar não serve para nada.
O Guia lista ainda cinco valores: compromisso, foco, abertura, respeito e coragem. Eles parecem genéricos, mas têm efeito concreto. Coragem é o desenvolvedor dizer na Daily Scrum que a Meta da Sprint está em risco. Abertura é o Product Owner admitir para o patrocinador que uma funcionalidade pedida não gerou o valor esperado.
Quem faz parte do Scrum Team
O Scrum Team tem um Product Owner, um Scrum Master e Developers, normalmente 10 pessoas ou menos, sem sub-times e sem hierarquia interna. O time é multifuncional (tem todas as habilidades para criar valor a cada Sprint) e autogerenciável (decide internamente quem faz o quê, quando e como). O Guia de 2020 fala em três responsabilidades, não em cargos:
| Responsabilidade | Responde por | Na prática |
|---|---|---|
| Product Owner | Maximizar o valor do produto | Define e comunica a Meta do Produto, cria e ordena os itens do Product Backlog. É uma pessoa, não um comitê; quem quiser mudar prioridades precisa convencê-la. |
| Scrum Master | Estabelecer o Scrum e a eficácia do time | Ensina o framework, provoca a remoção de impedimentos, ajuda o Product Owner com técnicas de backlog e apoia a organização na adoção. O Guia o descreve como um líder que serve. |
| Developers | Criar o incremento utilizável a cada Sprint | Montam o Sprint Backlog, seguem a Definição de Pronto, ajustam o plano todo dia e se cobram como profissionais. "Developers" vale para qualquer especialidade, não só programação. |
Repare que não existe gerente de projetos no Scrum Team. Isso não significa que o profissional de projetos perde espaço, e sim que as atribuições dele se redistribuem entre os três papéis. O artigo sobre Scrum para gerentes de projetos tradicionais mostra como fazer essa transição.
Como o Scrum funciona: os cinco eventos
A Sprint é o evento que contém os outros quatro. Tem duração fixa de um mês ou menos e uma nova começa assim que a anterior termina. Durante a Sprint, nenhuma mudança pode pôr em risco a Meta da Sprint e a qualidade não pode cair, mas o escopo pode ser renegociado com o Product Owner conforme o time aprende. Só o Product Owner pode cancelar uma Sprint, e só quando a Meta da Sprint se torna obsoleta.
| Evento | Para que serve | Duração máxima (Sprint de um mês) |
|---|---|---|
| Sprint Planning | Responder por que a Sprint é valiosa (Meta da Sprint), o que pode ser feito e como o trabalho será realizado | 8 horas |
| Daily Scrum | Os Developers inspecionam o progresso rumo à Meta da Sprint e ajustam o plano do dia | 15 minutos |
| Sprint Review | Inspecionar o resultado com os stakeholders e decidir as próximas adaptações | 4 horas |
| Sprint Retrospective | Planejar formas de aumentar a qualidade e a eficácia do time | 3 horas |
Em Sprints mais curtas, os eventos costumam ser mais curtos. Três detalhes que muita gente erra:
- A Daily Scrum não tem formato obrigatório. As "três perguntas" saíram do Guia em 2020; os Developers escolhem a estrutura, desde que o foco seja a Meta da Sprint.
- A Sprint Review é uma sessão de trabalho, não uma apresentação, e nunca deve ser tratada como o único momento para liberar valor. Um incremento pode ser entregue antes do fim da Sprint.
- O refinamento do Product Backlog (quebrar e detalhar itens) não é um evento. É uma atividade contínua, feita quando o time precisar.
A retrospectiva é o evento mais negligenciado e o que mais gera ganho com o tempo. Se as suas terminam sem nenhuma mudança concreta, veja como fazer uma retrospectiva ágil que gera melhorias reais.
Os três artefatos e seus compromissos
Cada artefato tem um compromisso que dá foco e permite medir o progresso. Essa estrutura é uma das novidades da versão 2020, explicadas em detalhe no artigo sobre o que mudou no Scrum Guide 2020.
| Artefato | O que é | Compromisso |
|---|---|---|
| Product Backlog | Lista ordenada e emergente do que é preciso para melhorar o produto; única fonte de trabalho do time | Meta do Produto: o objetivo de longo prazo, que o time cumpre (ou abandona) antes de assumir outro |
| Sprint Backlog | Meta da Sprint (por quê), itens selecionados (o quê) e plano de entrega (como); é um plano dos Developers para os Developers | Meta da Sprint: o único objetivo da Sprint |
| Incremento | Passo concreto rumo à Meta do Produto, somado aos anteriores e utilizável | Definição de Pronto: a descrição formal da qualidade exigida |
A Definição de Pronto é o ponto mais prático do framework. Um item que não a atende não pode ser liberado nem apresentado na Sprint Review: volta para o Product Backlog. É ela que acaba com o "está 90% pronto". Para montar a lista que alimenta tudo isso, veja como criar o seu primeiro backlog de produto.
Exemplo de Sprint na prática
Imagine, como exemplo ilustrativo, uma rede de clínicas que está criando um aplicativo de agendamento de consultas. O time tem um Product Owner da área de atendimento, um Scrum Master e cinco Developers (desenvolvimento, testes e design). A Meta do Produto é "o paciente agenda, remarca e cancela consultas sem ligar para a central". As Sprints duram duas semanas.
- Sprint Planning (segunda-feira, cerca de 4 horas). O Product Owner propõe o que traria mais valor agora. O time define a Meta da Sprint: "o paciente consegue remarcar uma consulta pelo aplicativo". Os Developers escolhem os itens do topo do backlog que cabem nas duas semanas e quebram cada um em tarefas de até um dia.
- Daily Scrum (todo dia, 15 minutos). Na quarta-feira da primeira semana, aparece um impedimento: a integração com o sistema da clínica não devolve os horários livres. O Scrum Master aciona a equipe responsável pelo sistema, e os Developers reorganizam o trabalho para não parar.
- Durante a Sprint. O Product Owner esclarece regras de negócio (até quantas horas antes o paciente pode remarcar?) e o time refina itens da próxima Sprint.
- Sprint Review (segunda sexta-feira, cerca de 2 horas). O time mostra a remarcação funcionando para a gerente de atendimento e duas recepcionistas. Elas pedem um aviso por SMS para a clínica. O Product Owner coloca o item no backlog e reordena.
- Sprint Retrospective (logo depois, cerca de 1h30). O time percebe que os testes de integração ficaram para o último dia e decide incluir "testado no ambiente da clínica" na Definição de Pronto.
No fim da Sprint, existe uma entrega que pacientes reais podem usar, e não um relatório de percentual concluído. Esse é o teste mais simples para saber se o Scrum está funcionando.
Erros comuns ao adotar a metodologia Scrum
- Daily Scrum como reunião de status para o chefe. Ela é dos Developers e serve para ajustar o plano rumo à Meta da Sprint.
- Product Owner por comitê ou sem tempo. O Guia é explícito: uma pessoa, com decisões respeitadas pela organização.
- Sprint sem meta. Uma lista de tarefas soltas não dá foco nem critério para negociar escopo quando algo dá errado.
- Scrum Master como secretário de reuniões. O papel é aumentar a eficácia do time e da organização, o que inclui enfrentar impedimentos fora do time.
- Sprints de duração variável. Esticar a Sprint para "terminar o que faltou" destrói a cadência que permite inspecionar e prever.
- Achar que Scrum é só para software. O Guia de 2020 tirou os termos específicos de TI justamente porque o framework é usado em outras áreas, como marketing, produto e projetos de inovação.
Se você está avaliando Scrum contra outras opções, o artigo que compara Kanban, Scrum e XP ajuda a decidir qual se encaixa no seu tipo de trabalho.
Para começar, escolha um projeto com resultado incerto e um cliente disponível, defina quem será o Product Owner, escreva a Meta do Produto em uma frase e rode três Sprints de duas semanas antes de avaliar. Se quiser dominar o framework com método, o curso Agile Scrum Foundation da Projeto Diário cobre papéis, eventos, artefatos e práticas ágeis complementares, e prepara você para o exame de certificação ASF.
