Quase todo texto sobre Scrum é escrito para quem vai trabalhar dentro de um time: o desenvolvedor, o futuro Scrum Master, o gestor que quer adotar o método. Só que uma parte grande de quem pesquisa o termo está do outro lado da mesa. É o dono de empresa ou o gestor que vai contratar um MVP e ouviu do fornecedor que "a gente trabalha com Scrum, em Sprints de duas semanas".
Este artigo explica o Scrum pelo que diz o Guia oficial, na versão de novembro de 2020, com os papéis, os eventos e os prazos corretos. E mostra o que quem contrata precisa combinar antes da primeira Sprint, com atenção especial à Definição de Pronto, que na prática funciona como o critério de aceite de cada entrega do MVP.
O que é Scrum?
O Guia do Scrum, de Ken Schwaber e Jeff Sutherland define o Scrum como um framework leve que ajuda pessoas, times e organizações a gerar valor por meio de soluções adaptativas para problemas complexos. Não é uma metodologia completa, com cada passo descrito: é uma estrutura mínima dentro da qual o time usa as técnicas que quiser.
Em resumo, o Guia descreve um ciclo de quatro movimentos. Um Product Owner ordena o trabalho de um problema complexo num Product Backlog. O Scrum Team transforma uma seleção desse trabalho num Incremento de valor durante uma Sprint. O time e as partes interessadas inspecionam o resultado e ajustam a próxima Sprint. E o ciclo se repete.
Para que serve o Scrum?
Serve para trabalhar em problemas em que não dá para saber tudo de antemão. O Guia apoia o Scrum no empirismo: só o que já aconteceu pode ser usado para decidir o que vem a seguir. Em vez de um plano fechado de seis meses, o time entrega algo utilizável a cada ciclo curto e corrige o rumo com base no que aprendeu.
Um MVP é o caso típico. Ninguém sabe ao certo quais funções os primeiros usuários vão usar. Entregar em Sprints permite colocar uma versão no ar cedo, medir e decidir a próxima com dados, em vez de descobrir no fim do projeto que metade do escopo não fazia falta.
De onde vem o Scrum?
Segundo o próprio Guia, Schwaber e Sutherland desenvolveram o Scrum no início dos anos 1990 e o apresentaram juntos pela primeira vez na conferência OOPSLA, em 1995. O Guia do Scrum é o documento em que os dois mantêm a definição oficial, revisada ao longo dos anos; a versão de novembro de 2020 é a vigente no site scrumguides.org.
Os dois autores também estão entre os signatários do Manifesto para Desenvolvimento Ágil de Software, de 2001, que resume os valores do movimento ágil, como "software em funcionamento mais que documentação abrangente" e "responder a mudanças mais que seguir um plano". O Scrum é uma das formas de colocar esses valores em prática.
A versão de 2020 trouxe mudanças que muitos textos ainda não incorporaram. O antigo "time de desenvolvimento" deixou de existir como subgrupo: agora há um único Scrum Team, e quem constrói o produto é chamado de Developers. E a versão introduziu a Meta do Produto como compromisso do Product Backlog.
Scrum e método ágil são a mesma coisa?
Não. "Ágil" é o conjunto de valores e princípios do Manifesto de 2001; Scrum é um framework específico que segue esses valores. Toda equipe que usa Scrum trabalha de forma ágil, mas há outras formas de trabalhar de forma ágil sem Scrum.
A comparação mais pedida é com o Kanban. O Kanban organiza o trabalho como um fluxo contínuo, visível num quadro, sem ciclos de duração fixa. O Scrum organiza em Sprints, com eventos e papéis definidos. Muitos times combinam os dois: Sprints do Scrum com um quadro Kanban para acompanhar o andamento.
| Scrum | Kanban | Projeto em cascata | |
|---|---|---|---|
| Ritmo | Sprints de duração fixa, de um mês ou menos | Fluxo contínuo, sem ciclos fixos | Fases sequenciais até a entrega final |
| Papéis | Product Owner, Scrum Master e Developers | Não define papéis obrigatórios | Gerente de projeto e equipe por fase |
| Mudança de escopo | Entra no Product Backlog e é ordenada pelo PO | Entra no fluxo quando há capacidade | Exige revisão formal do plano |
| Quando o cliente vê algo funcionando | A cada Sprint, na Sprint Review | Quando cada item termina | No fim do projeto ou de grandes fases |
| Combina melhor com | Produto novo, com muita incerteza | Demanda contínua, como sustentação | Escopo estável e bem conhecido |
Elaborado pela Alliance Comunicação. Características do Scrum conforme o Guia do Scrum de 2020.
Como funciona o Scrum na prática?
Tudo acontece dentro da Sprint, que o Guia chama de "coração do Scrum". Uma Sprint começa logo depois que a anterior termina, e nela cabem os outros quatro eventos. Cada evento tem um timebox, uma duração máxima, definida para uma Sprint de um mês.
- Sprint Planning. Abre a Sprint e responde três perguntas: por que esta Sprint tem valor (a Meta da Sprint), o que pode ficar pronto e como o trabalho será feito.
- Daily Scrum. 15 minutos, todo dia útil, no mesmo horário e lugar, para os Developers inspecionarem o progresso rumo à Meta da Sprint e ajustarem o plano do dia seguinte.
- Sprint Review. O time apresenta o resultado às partes interessadas e todos discutem o que fazer a seguir. O Guia pede que seja uma sessão de trabalho, não uma apresentação.
- Sprint Retrospective. Encerra a Sprint. O time revisa como trabalhou, inclusive a própria Definição de Pronto, e escolhe melhorias para o próximo ciclo.
Um detalhe que muitos guias erram: Sprints de duas semanas são uma escolha comum, mas não uma regra. O Guia fixa só o teto de um mês e lembra que Sprints mais curtas geram mais ciclos de aprendizado e limitam o risco de custo e esforço a um período menor.
Quem faz o quê no Scrum Team?
O Scrum Team é pequeno, normalmente com 10 pessoas ou menos, multifuncional (tem todas as competências para entregar valor a cada Sprint) e autogerenciado (decide internamente quem faz o quê, quando e como). Dentro dele, o Guia define três responsabilidades:
- Product Owner (PO). Responde por 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ê.
- Scrum Master. Responde pela eficácia do time e por estabelecer o Scrum como o Guia define: treina o time, remove impedimentos, ajuda o PO a gerir o backlog e garante que os eventos aconteçam dentro do timebox.
- Developers. Quem constrói o Incremento a cada Sprint. Respondem pelo plano da Sprint, pela qualidade, seguindo a Definição de Pronto, e por adaptar o plano todos os dias.
Para quem contrata, a pergunta decisiva é quem será o Product Owner. O Guia diz que as decisões do PO precisam ser respeitadas por toda a organização e que quem quiser mudar o backlog deve convencê-lo. Se o PO é alguém do fornecedor, as prioridades do seu produto estão sendo decididas fora da sua empresa. O artigo sobre fábrica de software e o papel que não se terceiriza trata exatamente desse ponto.
Quais são os artefatos do Scrum?
O Guia define três artefatos, e cada um tem um compromisso associado, que dá ao time um alvo contra o qual medir o progresso:
| Artefato | O que é | Compromisso | O que o compromisso diz |
|---|---|---|---|
| Product Backlog | Lista ordenada e em evolução do que é preciso para melhorar o produto | Meta do Produto | O estado futuro do produto que serve de alvo para o planejamento |
| Sprint Backlog | Meta da Sprint, itens escolhidos e plano para entregá-los | Meta da Sprint | O objetivo único daquela Sprint |
| Incremento | Passo concreto rumo à Meta do Produto, utilizável e somado aos anteriores | Definição de Pronto | O padrão de qualidade que a entrega precisa atingir |
Ken Schwaber e Jeff Sutherland, The Scrum Guide (versão de novembro de 2020).
O backlog é a única fonte de trabalho do time. Itens grandes são quebrados e detalhados num trabalho contínuo chamado refinamento, e quem estima o tamanho de cada item são os Developers que vão fazê-lo. O PO pode influenciar, ajudando a entender as escolhas, mas não define a estimativa.
O que é a Definição de Pronto e por que ela é o aceite do MVP?
O Guia define a Definição de Pronto (Definition of Done) como a descrição formal do estado do Incremento quando ele atende às medidas de qualidade exigidas para o produto. No momento em que um item do backlog atende a essa definição, nasce um Incremento.
A consequência prática é a regra mais importante para quem contrata: se um item não atende à Definição de Pronto, ele não pode ser liberado nem sequer apresentado na Sprint Review. Volta para o backlog. Sem uma definição escrita, "pronto" passa a significar o que cada lado quiser, e a discussão sobre o que foi entregue vira discussão sobre o que foi combinado.
O Guia também diz quem a escreve. Se a organização já tem um padrão de pronto, todos os times seguem no mínimo esse padrão. Se não tem, o Scrum Team precisa criar uma definição adequada ao produto. Num MVP terceirizado, o cliente é parte interessada direta: é ele quem sabe que qualidade o produto precisa ter para ir ao ar, e a definição deveria ser acordada antes da primeira Sprint.
| Item da Definição de Pronto | Exemplo para um MVP | Como o cliente confere |
|---|---|---|
| Funciona no ambiente de teste | Publicado num endereço que o cliente consegue abrir | Acessa e usa a função ele mesmo |
| Critérios de aceite atendidos | Cada item do backlog tem critérios escritos e todos passam | Repete os passos descritos no item |
| Testado | Testes automatizados nas regras críticas, como cobrança e cadastro | Pede o relatório dos testes da Sprint |
| Mede o que precisa medir | Eventos de uso registrados na ferramenta de análise | Vê o evento aparecer depois de usar a função |
| Seguro o bastante para o estágio | Dados pessoais protegidos e acessos com senha | Pergunta como os dados estão guardados |
| Documentado no mínimo | Instruções para publicar e para rodar o projeto | Confere se outro fornecedor conseguiria continuar |
Elaborado pela Alliance Comunicação como exemplo; o Guia do Scrum não lista itens, apenas exige que a definição exista.
O que o cliente precisa combinar antes da primeira Sprint?
Contratar um MVP em Sprints não dispensa combinações; muda quais combinações importam. Estas seis valem a reunião inicial inteira:
1. Quem é o Product Owner
Uma pessoa, com nome, com tempo na agenda e com autoridade para decidir prioridades. De preferência, do lado do cliente. Se for do fornecedor, combine como as prioridades serão validadas com você a cada Sprint.
2. A Meta do Produto
Uma frase que descreve o estado que o MVP precisa alcançar, como "cliente consegue se cadastrar, contratar o plano e usar a função principal sem ajuda". Ela é o alvo contra o qual se decide o que entra e o que fica para depois.
3. A Definição de Pronto
Escrita, curta e verificável. É o que transforma "a Sprint terminou" em "a Sprint entregou". Revise-a nas retrospectivas, como o Guia prevê.
4. A duração da Sprint
Até um mês, pelo Guia. Para um MVP, Sprints mais curtas dão mais pontos de inspeção, mas cada uma precisa ser longa o bastante para gerar um Incremento utilizável.
5. A sua presença na Sprint Review
É o momento em que você vê o produto funcionando e decide o rumo com o time. Se ninguém do cliente participa, o feedback chega tarde e o backlog é ordenado sem quem conhece o negócio.
6. O que acontece com o que não ficou pronto
Pelo Guia, volta para o backlog. Combine como isso aparece no relatório da Sprint e como afeta o que é faturado, se o contrato for por Sprint. Os detalhes de contrato estão fora deste artigo, mas a regra precisa estar clara para os dois lados.
Quais os erros mais comuns ao contratar um MVP em Sprints?
- Aceitar "Scrum" como sinônimo de "sem escopo". O Scrum troca o escopo fechado por uma Meta do Produto e um backlog ordenado. Sem os dois, não há base para decidir nada.
- Deixar o PO do lado do fornecedor sem combinar validação. Quem ordena o backlog decide o produto.
- Não ter Definição de Pronto escrita. Cada Review vira negociação sobre o que conta como entregue.
- Tratar a Review como apresentação. O Guia pede sessão de trabalho, com as partes interessadas decidindo o próximo passo.
- Mudar a meta no meio da Sprint. O Guia diz que, durante a Sprint, não se fazem mudanças que coloquem em risco a Meta da Sprint. Se ela ficar obsoleta, só o PO pode cancelar a Sprint.
- Adotar só parte do Scrum. O Guia é explícito: implementar só partes é possível, mas o resultado não é Scrum. Sem retrospectiva ou sem Definição de Pronto, o ciclo de melhoria quebra.
O método Scrum é válido para qualquer tipo de empresa?
O Guia não restringe o Scrum a software: fala em times e organizações que lidam com problemas complexos. O framework é usado em marketing, produto e pesquisa, e funciona melhor onde há incerteza real sobre o que precisa ser feito.
Onde o trabalho é repetitivo e previsível, como manutenção de um sistema estável ou atendimento de chamados, os ciclos fixos podem atrapalhar mais do que ajudar, e um fluxo contínuo costuma servir melhor. Para um MVP, que é por definição um experimento, o Scrum encaixa bem: cada Sprint é uma pequena aposta, inspecionada no fim. O que se aprende ali alimenta o que o protótipo não responde e o que só o produto em uso consegue mostrar.
Por onde começar hoje?
- Leia o Guia do Scrum de 2020: é curto e gratuito, e é a régua para conferir o que o fornecedor chama de Scrum.
- Defina quem, na sua empresa, será o Product Owner do MVP e reserve tempo na agenda dessa pessoa.
- Escreva a Meta do Produto em uma frase.
- Peça ao fornecedor uma proposta de Definição de Pronto e ajuste-a junto, antes da primeira Sprint.
- Marque na agenda todas as Sprint Reviews do projeto e trate-as como reuniões de decisão.
Se você está avaliando como tirar um produto do papel, o trabalho de desenvolvimento de MVP da Alliance começa por essas combinações. E se quer uma visão geral de onde a empresa está em marketing, dados e tecnologia, o diagnóstico de marketing gratuito leva cerca de 30 minutos e aponta as prioridades por área.