Metodologia Scrum: o guia completo (e por que Scrum não é metodologia)

Quase todo texto em português chama Scrum de metodologia. O documento oficial que o define, o Scrum Guide, escrito pelos dois criadores, abre dizendo que ele é um framework leve. A diferença não é preciosismo de vocabulário: ela explica por que tanta empresa diz que faz Scrum e não colhe nada.

Este texto percorre o framework como ele está definido hoje, na revisão de 2020: três pilares, cinco valores, três responsabilidades, cinco eventos e três artefatos. E termina no assunto que quase ninguém trata, que é quando Scrum não é a escolha certa.

Framework, não metodologia

Uma metodologia diz o que fazer. Ela entrega a sequência de passos, e você a segue. Um framework diz onde as decisões acontecem, quem decide e com que frequência, e deixa o conteúdo das decisões com você.

Scrum é do segundo tipo, e é deliberadamente incompleto. Não diz como estimar, não escolhe ferramenta, não define quantos testes escrever. Cabe ao time preencher esses espaços, e é por isso que dois times fazendo Scrum corretamente podem trabalhar de formas bem diferentes.

Essa incompletude é a origem do problema mais comum. Quem espera receita adota os rituais, mantém o resto como estava, e conclui em seis meses que Scrum não funciona. O que não funcionou foi tratar moldura como manual. Scrum é o mais adotado dos métodos ágeis, o que ajuda a explicar por que é também o mais deturpado.

Os 3 pilares e os 5 valores

Scrum se apoia no empirismo: decisões saem da observação do que aconteceu, não da previsão do que deveria acontecer. Isso se sustenta em três pilares, e vale ler cada um como uma pergunta:

• Transparência. O trabalho e o resultado estão visíveis para quem faz e para quem recebe? Processo opaco impede inspeção, e inspeção sem transparência produz decisão errada com aparência de dado.
• Inspeção. Os artefatos e o progresso são examinados com frequência suficiente para detectar desvio? Inspeção rara transforma pequeno desvio em retrabalho grande.
• Adaptação. Quando o desvio aparece, alguma coisa muda? Inspecionar e não ajustar é teatro, e é o estágio final de quase toda adoção que fracassa.

Sobre os pilares ficam cinco valores: compromisso, foco, abertura, respeito e coragem. Parecem enfeite de parede até o dia em que faltam. Sem abertura ninguém diz que a tarefa não vai sair, e a Daily vira relatório de fachada. Sem coragem, ninguém aponta que o objetivo da Sprint deixou de fazer sentido na terça-feira.

As 3 responsabilidades

O Scrum Team tem até dez pessoas, sem subtimes e sem hierarquia interna. Dentro dele existem três responsabilidades, e as duas primeiras são as mais mal compreendidas do framework:

Vale insistir no Scrum Master, porque o erro é caro e este blog já o cometeu ao descrevê-lo como um líder com bom conhecimento técnico para orientar os desenvolvedores. Não é isso. O Scrum Guide o define como um líder que serve, e a diferença aparece na prática: um líder técnico responde perguntas de implementação, um Scrum Master remove o motivo pelo qual a pergunta ficou dois dias sem resposta. Quando a mesma pessoa acumula os dois papéis, o time perde quem cuidava do processo, porque a urgência técnica sempre ganha.

O outro erro comum é distribuir as tarefas na Planning, com um responsável por item. Isso desmonta a auto-organização que faz o framework funcionar: os Developers puxam o trabalho conforme a Sprint anda, e a capacidade de remanejar no meio do caminho é justamente o que se está comprando. Times que funcionam assim tendem a ser os mesmos que conseguem operar com autonomia real.

Os 5 eventos e seus prazos

São cinco, e o primeiro contém os outros quatro. Todos têm prazo máximo, e o prazo é parte da regra, não sugestão:

Os prazos valem para uma Sprint de um mês e encurtam proporcionalmente: em Sprint de duas semanas, a Planning tem até quatro horas.

Dois pontos merecem atenção. A Daily é dos Developers, não é reunião de status para um gestor, e o Scrum Guide de 2020 removeu as três perguntas obrigatórias que todo mundo ainda recita. E a Review não é uma demonstração: é uma sessão de trabalho em que quem recebe o produto opina e o backlog muda ali. Apresentação em que ninguém pode discordar não é Review.

A Retrospective é o evento que primeiro é sacrificado quando o prazo aperta, e é o único cuja função é melhorar o próprio time. Ela funciona melhor com uma técnica de investigação por trás: os 5 porquês são a mais barata para chegar da reclamação até a causa.

Os 3 artefatos e seus compromissos

Cada artefato carrega um compromisso, que é o que dá a ele um critério de avaliação. Sem o compromisso, o artefato vira lista solta:

Aqui mora outra confusão frequente, que também já apareceu neste blog: descrever o backlog como a lista de tarefas necessárias para concluir um projeto. O Product Backlog não é isso. Ele é do produto, não do projeto, não tem fim previsto, e é ordenado por valor, não por sequência de execução. A lista de tarefas de um período específico é o Sprint Backlog, e é outra coisa.

A Definition of Done é o artefato invisível que mais separa time maduro de time que só usa o vocabulário. Sem ela, cada pessoa tem um conceito próprio de pronto, e o Incremento acumula dívida silenciosa até virar uma fase de estabilização que ninguém planejou.

Uma Sprint de ponta a ponta

Uma empresa quer que o cliente acompanhe o pedido sem ligar para o atendimento. Esse é o Product Goal. O Product Backlog reúne o que serve a ele: consulta por número do pedido, notificação de mudança de etapa, histórico, cancelamento.

Na Planning, o time define o Sprint Goal das próximas duas semanas: permitir que o cliente consulte a situação do pedido sozinho. Note que o objetivo não é uma lista de tarefas, é um resultado. Isso importa porque permite ao time trocar o caminho no meio da Sprint sem perder o rumo. Os Developers escolhem os itens que servem ao objetivo e montam o plano.

Durante a Sprint, as Dailies ajustam o plano. Na quarta-feira descobre-se que a integração com a transportadora demora mais do que o previsto. O time decide entregar a consulta com os dados internos primeiro, o que ainda cumpre o Sprint Goal, e leva a integração para o backlog. Nada disso exige aprovação de fora: é o time se organizando dentro do objetivo acordado.

Na Review, o time mostra a consulta funcionando para o atendimento e o comercial. Alguém observa que metade das ligações pergunta pela nota fiscal, não pela entrega. Essa informação vale mais que a funcionalidade entregue, e o backlog muda por causa dela. Na Retrospective, trata-se do que atrasou a integração.

Repare no formato do que foi entregue: um recorte pequeno e usável, colocado diante de gente real para produzir aprendizado. É a mesma lógica de um MVP de produto digital, aplicada dentro de cada ciclo em vez de uma vez só no começo.

Quando Scrum não é a escolha certa

Scrum foi desenhado para trabalho com incerteza alta, em que o que se aprende no caminho muda o que se vai fazer. Quando essa incerteza não existe, a estrutura vira custo sem contrapartida.

Migrar bases de dados para um servidor externo é o exemplo perfeito do que não pede Scrum, e este blog já o usou como se pedisse. O escopo é conhecido, a ordem das etapas é técnica, e não há hipótese sobre o comportamento de usuário para testar. Não existe nada de útil a inspecionar a cada duas semanas que já não esteja num cronograma. Trabalho assim se beneficia de um fluxo contínuo com limite de trabalho em progresso, no estilo Kanban, ou de um plano por etapas mesmo.

A regra prática funciona bem em três perguntas. O que vamos construir pode mudar por causa do que aprendermos? Se não, Scrum tem pouco a oferecer. Existe alguém com autoridade para reordenar as prioridades? Sem um Product Owner de verdade, as Sprints viram fatias arbitrárias de um plano fixo. O time consegue entregar algo utilizável em uma Sprint? Se depende de três áreas externas para qualquer entrega, o problema é a estrutura, e nenhum ritual resolve isso.

Quando as três respostas são sim, o framework paga por si em poucos ciclos. Quando não são, o mais honesto é escolher outra forma de trabalhar, o que é uma decisão de como conduzir desenvolvimento de software e não uma questão de disciplina do time. Adotar Scrum onde ele não cabe é uma das formas mais comuns de confundir novidade com inovação de verdade: troca-se o vocabulário e mantém-se o problema.

Perguntas frequentes