O Scrum é um framework para equipes que precisam entregar valor em ambiente de incerteza: em vez de planejar tudo e entregar no fim, a equipe trabalha em ciclos curtos, mostra o resultado a cada ciclo e ajusta o rumo. Para a prefeitura, é útil em iniciativas em que a necessidade muda, como um sistema novo, um serviço digital ou uma campanha. Este texto explica como o Scrum funciona, onde ele serve e onde não serve, e como começar sem virar modismo.
O que é e de onde vem
O Scrum foi criado por Ken Schwaber e Jeff Sutherland, que mantêm o Scrum Guide, o documento oficial do método. A versão vigente é a de 2020, com menos de treze páginas, e o histórico de revisões mostra um guia que ficou mais curto e menos prescritivo com o tempo. A página das revisões do guia informa que o uso do Scrum se espalhou pelo mundo a partir do início dos anos 1990. Segundo relatos da comunidade Scrum, Schwaber e Sutherland o apresentaram formalmente na conferência OOPSLA em 1995, e a primeira edição do Scrum Guide é de 2010. Há historiadores do método que discutem se o artigo é de 1995 ou 1996, por isso tratamos a data como “meados dos anos 1990”.
Segundo o guia, o Scrum é um framework leve que ajuda pessoas, equipes e organizações a gerar valor por meio de soluções adaptativas para problemas complexos. Ele se apoia em três pilares: transparência, inspeção e adaptação, e em cinco valores: comprometimento, foco, abertura, respeito e coragem.
A equipe Scrum é pequena, multifuncional e autogerenciável, com três papéis: o Product Owner, que cuida do valor e da ordem dos itens a fazer; o Scrum Master, que ajuda a equipe a entender e praticar o método; e os Developers, que fazem o trabalho. Os eventos são a Sprint (ciclo de duração fixa de até um mês), o planejamento, a reunião diária de quinze minutos, a revisão com os interessados e a retrospectiva. Os artefatos são o Product Backlog (lista ordenada do que se quer), o Sprint Backlog e o incremento.
Por que pode funcionar no setor público
Muitos projetos públicos falham porque tentam prever tudo antes de começar: a necessidade muda, a lei muda, o usuário descobre o que quer apenas quando vê o primeiro resultado. Ciclos curtos com entrega visível reduzem esse risco, porque o erro é descoberto em semanas e não em meses.
O método também cria um ritual de transparência: todo mês, quem usa o serviço ou patrocina o projeto vê o que foi feito. Mas há limites. Contratos com escopo fechado, prestação de contas formal e licitações exigem adaptações, e nem toda atividade pública é projeto: rotina contínua de atendimento é melhor tratada por métodos de fluxo e melhoria de processos.
Como aplicar na prefeitura, passo a passo
- Escolha uma iniciativa com incerteza. Serviços digitais, sistemas internos e campanhas são bons candidatos. Obras com projeto fechado, nem tanto.
- Defina o responsável pelo valor. O Product Owner é uma pessoa com autoridade para decidir o que entra primeiro. Em órgão público, costuma ser o gestor da área beneficiada.
- Monte o backlog. Liste o que se quer, com linguagem do usuário, e ordene por valor e urgência.
- Defina a duração da sprint. Duas semanas é um padrão comum. Mantenha fixa para criar ritmo.
- Planeje a sprint com uma meta. A equipe escolhe o que cabe no ciclo e escreve a meta da sprint em uma frase.
- Faça a reunião diária. Quinze minutos para ver o que avançou, o que trava e o que fazer a seguir.
- Mostre e aprenda. Ao final, revise o resultado com os interessados, ajuste o backlog e faça uma retrospectiva sobre como a equipe trabalhou.
Modelo para preencher
Use a ficha abaixo como ponto de partida. Adapte à legislação e à realidade do seu órgão.
| Item do backlog | Valor para o usuário | Prioridade | Sprint | Situação |
|---|---|---|---|---|
| Necessidade 1, na voz do usuário | ||||
| Necessidade 2 | ||||
| Necessidade 3 | ||||
| Melhoria técnica ou ajuste de processo | ||||
| Dúvida a investigar |
Exemplo prático
Exemplo hipotético. Uma secretaria quer um canal digital para solicitar a segunda via de documentos. Em vez de especificar tudo antes de contratar, a equipe monta um backlog e define sprints de duas semanas. Na primeira, entrega um formulário simples para um único documento e o mostra a servidores do balcão.
A revisão aponta que o formulário pede dados demais e que a consulta de andamento é mais importante que a solicitação. O backlog é reordenado. Na segunda sprint, a consulta passa a ser entregue primeiro. Em dois meses, o serviço está no ar com o que os usuários realmente usam, sem grandes retrabalhos.
Erros comuns
- Chamar de Scrum o que é reunião diária. Sem backlog ordenado, meta e revisão com interessados, é apenas um ritual.
- Product Owner sem autoridade. Se tudo depende de aprovação superior, o ciclo curto perde o sentido.
- Sprints sem entrega visível. O objetivo é mostrar algo funcionando. Relatórios de atividade não bastam.
- Ignorar o contexto legal. Contratação, prestação de contas e controle exigem adaptação. Combine com o jurídico e o controle interno desde o início.
- Adotar para tudo. Rotinas contínuas e obras com projeto fechado têm métodos mais adequados.
Perguntas frequentes
Quem criou o Scrum?
Ken Schwaber e Jeff Sutherland, autores do Scrum Guide, cuja versão vigente é de 2020.
Scrum é a mesma coisa que métodos ágeis?
Scrum é um dos frameworks ágeis. O Manifesto Ágil, de 2001, reúne os valores que inspiram o Scrum e outros métodos.
É possível usar Scrum com licitação?
É possível, com adaptações: a contratação deve prever entregas em etapas e mecanismos de aceite. Consulte o jurídico e o controle interno.
Qual o tamanho ideal da equipe?
O guia fala em equipe pequena e multifuncional. O importante é que reúna as competências necessárias.
