Definition of Done: por que seu time precisa de uma
Um item está “pronto” quando o código está escrito? Quando passou em teste? Quando está em produção? Se seu time tem opiniões diferentes sobre isso, precisa de uma Definition of Done (DoD).
O que é Definition of Done
A DoD é um acordo do time sobre o que significa “terminado”. É o checklist que todo item deve satisfazer antes de ser considerado concluído. Sem ela, um desenvolvedor pode marcar algo como done enquanto outro diria que falta documentação.
Exemplo de DoD genérica
- Código escrito e funcional
- Code review aprovado por pelo menos 1 colega
- Testes unitários passando (cobertura mínima de 80%)
- Testes de integração passando
- Documentação atualizada (se aplicável)
- Deploy em staging validado
- Sem issues de lint ou análise estática
- Critérios de aceitação do PO atendidos
DoD por tipo de time
Time de produto (feature development)
- Código revisado
- Testes unitários e E2E
- Feature flag configurada
- Analytics tracking implementado
- Documentação de API atualizada
Time de plataforma/infra
- Infraestrutura como código versionada
- Pipeline de CI/CD funcionando
- Monitoramento e alertas configurados
- Runbook documentado
- Rollback tested
Time de dados/ML
- Qualidade de dados verificada
- Modelo versionado e reproduzível
- Benchmarks de performance atendidos
- Documentação do pipeline
- Compliance e LGPD verificados
DoD vs Critérios de Aceitação
Definition of Done aplica-se a todos os itens do sprint. É o padrão de qualidade do time.
Critérios de Aceitação são específicos por história de usuário. Exemplo: “O botão de checkout deve redirecionar para a página de pagamento em menos de 2 segundos.”
Um item só está done quando atende ambos.
Como criar sua DoD
- Reúna o time — toda a equipe deve participar
- Liste o que já faz — comece com as práticas que já seguem
- Adicione o ideal — o que vocês gostariam de fazer
- Priorize — comece com 4-6 itens, não 20
- Revise a cada sprint — a DoD evolui com a maturidade do time
Armadilhas comuns
DoD impossível
Se o time não consegue cumprir a DoD em todos os itens, ela está muito ambiciosa. Reduza e construa gradualmente.
DoD ignorada
Se itens são marcados como done sem atender a DoD, há um problema cultural. O Scrum Master precisa reforçar a importância.
DoD genérica demais
“O código deve estar bom” não é acionável. Use critérios mensuráveis: “Cobertura de testes acima de 80%”, “Zero warnings de lint”.
DoD e estimativas
A DoD impacta diretamente as estimativas. Se sua DoD inclui testes E2E e documentação, esses esforços devem estar incluídos nos pontos de história da estimativa — não são “extras” feitos depois.
Conclusão
Uma boa Definition of Done é o contrato de qualidade do time. Ela elimina ambiguidade, protege a qualidade e garante que “pronto” significa a mesma coisa para todos. Comece simples, seja específico e revise regularmente.