DoD e DoR são acordos do time, não documentos formais. O objetivo é evitar conversas como "achei que estava pronto" e "essa story não estava clara o suficiente". Origem em XP/ Scrum (Kent Beck, Jeff Sutherland). O ato de articular explícito previne disputa depois. Times maduros revisitam DoD/ DoR em retrospectivas — não são pedras tabletadas, evoluem conforme o time descobre o que faltava.
Template
# Definition of Ready & Definition of Done — [Time/Squad]
> Acordo do time. Atualizado em [YYYY-MM-DD].
> Próxima revisão: [retrospectiva trimestral].
---
## Definition of Ready (DoR)
**Uma story só entra em sprint se TODOS os critérios são atendidos.**
### Story-level
- [ ] Story em formato "As a... I want... So that..."
- [ ] Acceptance criteria em Gherkin (G/W/T) escritos
- [ ] Mockups/wireframes anexados se há mudança de UI
- [ ] Dependências identificadas e resolvidas (ou plano para resolver)
- [ ] Story estimada (story points ou T-shirt size) por >1 pessoa
- [ ] Out of scope explícito
- [ ] PM disponível para responder dúvidas durante o sprint
### Cross-functional
- [ ] Design aprovou wireframes (se aplicável)
- [ ] Tech lead validou viabilidade
- [ ] Security olhou (se feature security-relevant)
- [ ] QA tem visibilidade do que vai ser testado
### Tamanho
- [ ] Story cabe em < metade do sprint (se maior, quebrar)
---
## Definition of Done (DoD)
**Uma story só vai para "Done" se TODOS os critérios são atendidos.**
### Código
- [ ] Mergeado em main (ou branch de release)
- [ ] Code review aprovado por >= 1 revisor
- [ ] Linter / static analysis passando sem warnings novos
- [ ] Build de CI verde
### Testes
- [ ] Unit tests cobrindo lógica de domínio
- [ ] Integration test do happy path
- [ ] E2E test se for feature crítica
- [ ] Cobertura de teste não regrediu (linha de base do time)
- [ ] Acceptance criteria validados manualmente em staging
### Qualidade
- [ ] Logs estruturados em pontos relevantes
- [ ] Métricas adicionadas se feature visível em produção
- [ ] Alertas atualizados se SLO afetado
- [ ] Performance dentro do esperado (smoke benchmark)
### Segurança
- [ ] Não introduz secret hardcoded
- [ ] Input validation em endpoints públicos
- [ ] Dependências sem vulnerabilidades críticas (scan limpo)
- [ ] Threat model revisitado se feature mudou superfície
### Documentação
- [ ] README/wiki atualizado se interface mudou
- [ ] ADR escrito se decisão arquitetural foi tomada
- [ ] Changelog atualizado
- [ ] Runbook atualizado se operação mudou
### Aceitação
- [ ] PM validou em staging
- [ ] Design validou se UI mudou
- [ ] Acessibilidade validada (WCAG AA mínimo)
- [ ] Sem regressões conhecidas em features adjacentes
### Pronto para release
- [ ] Feature flag configurada se rollout gradual
- [ ] Plano de rollback documentado
- [ ] Stakeholders notificados (se aplicável)
---
## Anti-padrões a evitar
- ❌ "DoD aprovado mas funciona só em dev" — todo critério precisa
ser checado em ambiente representativo
- ❌ "Vamos pular X só nesta story" — exceção pontual vira norma
- ❌ DoR/DoD que ninguém lembra ou consulta — afixar; revisar em
retro
DoD que não é checado é decoração. A regra prática: o DoD precisa ser visível durante o sprint review (afixado no canal de standup, no template do PR, no quadro). Se ninguém do time consegue listar de cabeça os principais itens, o DoD virou ficção. Renove em retro até funcionar como verificação real.
Referências
- Scrum Guide — Definition of Done
- Kent Beck, Extreme Programming Explained (1999)
- Agile Alliance — Definition of Ready
- Jeff Sutherland, Ken Schwaber — origem do Scrum