Definition of Done, Definition of Ready e por que essa disciplina muda o jogo no Desenvolvimento de Software.

Quando um time domina o que entra e o que sai do fluxo de trabalho, produtividade e qualidade deixam de ser sorte e viram rotina. É aqui que brilham dois termos simples — Definition of Ready (DoR) e Definition of Done (DoD) — capazes de reduzir retrabalho, aumentar previsibilidade e elevar a moral do time. Este artigo explica, motiva e dá passos práticos para aplicar essa disciplina com clareza no seu departamento.

O que é Definition of Ready (DoR)?

A DoR é o checklist de entrada: os critérios mínimos para que um item (história, bug, spike) seja considerado “pronto para começar”.
Se algo falha aqui, o time começa no escuro — e paga o preço depois.

Exemplo de DoR (ajuste ao seu contexto)

Objetivo de negócio claro e valor esperado descrito.
Critérios de aceitação escritos em formato testável (ex.: Gherkin ou Given/When/Then).
Escopo e limites definidos (o que não será feito agora).
Dependências mapeadas e viáveis (design, API de terceiros, dados).
Protótipos/UX aprovados quando aplicável.
Riscos conhecidos e plano de mitigação inicial.
Métricas de sucesso (ex.: conversão, tempo de resposta, NPS) definidas.
Estimativa e tamanho adequados ao Sprint (ou fluxo contínuo).
QA/Segurança cientes de cenários especiais (ex.: LGPD, PII).

Benefício: o time começa com menos interrupções, menos dúvidas e menor variabilidade.

O que é Definition of Done (DoD)?

A DoD é o checklist de saída: o que precisa ser verdade para considerar o item realmente concluído. Não é “codado”, é “entregue com qualidade”.

Exemplo de DoD (ajuste ao seu contexto)

Critérios de aceitação validados e 100% verdes.
Testes automatizados (unitários e/ou integração) cobrindo caminhos críticos.
Revisão de código realizada e feedback aplicado.
Segurança/Compliance checados (ex.: OWASP top 10 relevantes).
Observabilidade: logs, métricas e alertas preparados.
Documentação essencial atualizada (README, ADR, contrato de API, change log).
Feature flag (se existir) configurada e plano de rollback definido.
Performance mínima validada (ex.: p95 de latência ≤ X ms).
Deploy realizado no ambiente-alvo ou pronto para release (conforme estratégia).
Comunicação feita: release notes para suporte/CS e stakeholders.

Benefício: menos “quase pronto”, mais entregas que não voltam como incêndio.

Por que aplicar DoR e DoD de forma clara?

Redução de retrabalho: problemas descobertos cedo custam menos.
Previsibilidade: critérios padronizados tornam estimativas e prazos mais confiáveis.
Qualidade consistente: o time codifica e valida com o mesmo padrão.
Segurança psicológica: clareza reduz conflitos e “achismos”.
Escalabilidade: novos membros entendem rapidamente como entregar.

Sem clareza, “pronto” vira opinião. Com DoR/DoD, vira compromisso verificável.

Erros comuns (e como evitar)

Checklists longos demais: comece essencial, evolua por inspeção/adaptação.
Copy-paste de outro time: adapte à sua realidade tecnológica e de negócio.
Esquecer observabilidade e segurança: inclua cedo; tirar depois é caro.
Não medir: sem métricas, a conversa volta a ser subjetiva.
Não treinar o negócio: DoR/DoD não é só do time técnico; PO e stakeholders precisam jogar junto.

Como implementar no Departamento (passo a passo)

Workshop de alinhamento (2h)
- Apresentar dores atuais (retrabalho, bugs pós-release, atrasos).
- Mostrar o propósito de DoR/DoD e benefícios.
- Co-criar a versão 1.0 dos checklists por squad (máx. 10 itens cada).
Padronizar o mínimo organizacional
- Defina 5–7 itens obrigatórios para todo o departamento (ex.: testes críticos, revisão de código, segurança básica, observabilidade).
- Permita variação por produto/tecnologia acima desse mínimo.
Integrar ao fluxo de trabalho
- DoR: gate no refinamento/planning. Cartões que não passam não entram.
- DoD: gate de merge/deploy. Sem DoD cumprida, não fecha.
Ferramentas
- Templates na ferramenta de gestão (Jira/Azure Boards/Trello).
- Pull request checklist (GitHub/GitLab/Bitbucket).
- Pipelines que checam testes e cobertura mínima.
- Dashboards (observabilidade) prontos para novas features.
Treinamento contínuo
- Onboarding inclui DoR/DoD.
- Revisão trimestral dos checklists (retrospectivas ampliadas).
Governança leve
- Um “Chapter Qualidade” ou “Tech Excellence” para manter coerência, sem burocratizar.
- Auditorias amigáveis: amostragem de itens entregues por sprint para verificar aderência.

Métricas para provar valor (antes e depois)

Lead Time por tipo de item.
Taxa de retrabalho (histórias reabertas ou bugs pós-release por release).
Defeitos em produção (por 1.000 linhas/por funcionalidade).
Taxa de cumprimento de DoR/DoD (itens que passaram sem exceções).
MTTR (tempo médio para recuperar).
Satisfação do time (pulse survey mensal).
Satisfação do cliente/usuário (NPS/CSAT da funcionalidade).

Registre uma linha de base por 4–6 semanas e compare após 2–3 ciclos.

Exemplos práticos de critérios

Critérios de aceitação (Given/When/Then)

Given que o usuário está autenticado, When acessa a página de faturas, Then deve ver apenas suas próprias faturas em até p95 ≤ 800 ms.

Observabilidade na prática

Logs com correlação de request-id.
Métricas de negócio (ex.: taxa de conversão do funil impactado).
Alerta acionável (limite, playbook e responsáveis definidos).

Segurança aplicada

Check automático de dependências vulneráveis no CI.
Dados sensíveis mascarados em logs.
Revisão de ameaças (risk checklist) para endpoints novos.

Perguntas frequentes

“Vai desacelerar?”
No começo, um pouco. Em 2–3 sprints, a redução de retrabalho compensa e acelera o fluxo.

“E quando precisar flexibilizar?”
Permita waivers excepcionais, com motivo registrado e plano de mitigação. Sem virar regra.

“Pode ser diferente por squad?”
Sim, acima do mínimo comum. O contexto de plataforma, mobile, data ou produto pede nuances.

Call to action

Marque um workshop de 2 horas nesta semana para cocriar a DoR/DoD 1.0.
Ative os checklists na ferramenta e no pipeline já no próximo ciclo.
Meça 3–4 métricas-chave por 60 dias e exponha os resultados.
Ajuste trimestralmente. Disciplina leve, evolução contínua.

Resultado esperado: menos surpresa, mais entrega com confiança.
Quando “pronto para começar” e “pronto de verdade” são inequívocos, o time trabalha melhor, o cliente sente a diferença e o departamento ganha reputação de previsível, seguro e rápido.