Sprint Zero: quando vale a pena e quando é desperdício
Sprint Zero é um sprint de preparação antes de começar a entregar valor. É polêmico: alguns defendem como necessário, outros dizem que é desperdício. A verdade está no meio.
O que faz sentido em um Sprint Zero
Setup de infraestrutura (bom)
- Configurar repositório, CI/CD, ambientes
- Definir stack tecnológico e padrões de código
- Criar projeto base com ferramentas configuradas
Alinhamento do time (bom)
- Definir Working Agreements
- Estabelecer Definition of Done e Definition of Ready
- Configurar ferramentas (board, comunicação)
Contexto de negócio (bom)
- PO apresenta visão do produto
- Workshop de Story Mapping ou Impact Mapping
- Identificar primeiros épicos e priorizar backlog
O que NÃO fazer em Sprint Zero
Arquitetura detalhada (ruim)
“Vamos definir toda a arquitetura antes de codificar.” Isso é waterfall disfarçado. Defina o básico e evolua.
Especificação completa de requisitos (ruim)
“Vamos escrever todas as histórias antes do primeiro sprint.” Impossível. Escreva as primeiras e detalhe conforme necessário.
Duração longa (ruim)
“O Sprint Zero vai durar 4 semanas.” Se precisa de 4 semanas para preparar, algo está errado. Máximo: 1 sprint normal.
Tempo ideal
1 sprint (2 semanas) é suficiente para:
- ✅ Setup de infraestrutura técnica
- ✅ Definição de processos
- ✅ Backlog inicial com 2-3 sprints de itens refinados
- ✅ Ambiente de dev funcionando para todos
Sprint Zero enxuto (recomendado)
Se quer minimizar o Sprint Zero:
| Dia | Atividade |
|---|---|
| 1 | Setup de repositório, CI, ambientes |
| 2 | Stack, padrões, ferramentas |
| 3 | Workshop de produto (visão, personas, Story Map) |
| 4 | Backlog inicial + refinamento dos primeiros itens |
| 5 | Definition of Done, Working Agreements, Planning do Sprint 1 |
Alternativa: Sprint Zero implícito
Em vez de chamar de “Sprint Zero”:
- Semana 1 do Sprint 1: setup + primeiros commits
- Primeiras histórias: “Como dev, quero ter o ambiente de dev configurado”
- Working Agreements: definidos na primeira retro
Isso elimina a necessidade de um sprint “que não entrega valor.”
Quando Sprint Zero é necessário
- Projeto greenfield — tudo do zero (infra, código, processos)
- Time novo — todos se conhecendo, sem processos
- Mudança de stack — migrando de tecnologia
Quando Sprint Zero é desperdício
- Time já estabelecido — já tem stack, processos e ferramentas
- Extensão de produto existente — código e infra já existem
- MVP rápido — cada dia sem entregar código é custo
Conclusão
Sprint Zero é aceitável quando bem delimitado: 1 sprint, foco em infraestrutura e alinhamento, sem over-engineering. Mas o melhor Sprint Zero é aquele que entrega algo de valor — mesmo que seja apenas o setup de CI/CD.