Definition of Done (DoD): O Que É, Exemplos Práticos e Checklist de Qualidade

Quantas vezes você já presenciou a seguinte conversa em uma equipe de tecnologia: "O desenvolvimento da história já terminou; agora só falta fazer os testes, ajustar os logs, escrever a documentação e subir para o ambiente de homologação"? No framework Scrum e nas melhores práticas globais de engenharia, essa frase encerra uma contradição lógica absoluta. Se ainda falta testar, documentar, revisar ou fazer deploy, o trabalho simplesmente não está pronto. Ele está apenas parcialmente codificado.

A crença perigosa de que algo está "90% pronto" é a principal responsável por criar a chamada Dívida Técnica Oculta (Hidden Technical Debt): bugs crônicos descobertos semanas após a entrega, retrabalhos dispendiosos, lentidão no banco de dados e lançamentos adiados às vésperas de datas comerciais críticas. Para extirpar de vez essa ambiguidade e garantir que todo incremento seja genuinamente utilizável, o Scrum estabeleceu a Definition of Done (DoD - Definição de Pronto).

Neste guia aprofundado, você vai dominar os fundamentos da DoD segundo o Scrum Guide 2020 e o Guia SBOK® (Scrum Body of Knowledge), a matriz comparativa definitiva entre Definition of Ready (DoR), Critérios de Aceite (AC) e Definition of Done (DoD), um checklist de qualidade profissional em cinco camadas operacionais, como aplicar a DoD fora da TI (em marketing e engenharia) e os erros mais destrutivos que rebaixam o padrão de entrega das empresas.

O que é a Definition of Done no framework Scrum oficial

Na versão 2020 do Scrum Guide, elaborado por Ken Schwaber e Jeff Sutherland, a Definição de Pronto foi elevada a um patamar de compromisso formal inegociável:

"A Definition of Done é uma 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 Product Backlog atende à Definition of Done, um Incremento nasce."

Essa frase contém três pilares conceituais fundamentais:

1. O nascimento do Incremento: Itens individuais de trabalho não são liberados de forma isolada; eles se integram ao todo para formar um incremento de produto. Uma funcionalidade só é considerada parte do incremento se cumprir 100% da DoD;
2. Potencialmente Utilizável e Liberável (Potentially Shippable): O incremento concluído deve estar em um estado de qualidade tão elevado e testado que o Product Owner poderia decidir colocá-lo em produção no mesmo instante para os clientes reais, sem a necessidade de nenhuma "fase de testes" posterior;
3. Proteção da Transparência: Se a qualidade do trabalho for subjetiva, ninguém na organização sabe o que realmente está pronto e o que é apenas código instável. A DoD estabelece um padrão compartilhado por desenvolvedores, lideranças e clientes.

No Guia SBOK® da SCRUMstudy, o conceito é abordado no processo Demonstrate and Validate Sprint e na definição dos Critérios de Aceitação Mínimos do Negócio. O SBOK reforça que a conformidade com a DoD é o que garante que o projeto não comprometa a governança corporativa nem gere passivos regulatórios para a empresa.

A Matriz Tripla: DoR vs Critérios de Aceite vs DoD

A confusão entre esses três conceitos é o erro mais recorrente tanto em exames de certificação internacional (SFC, SMC, PSPO) quanto no chão da operação diária. Para nunca mais confundir, examine a matriz estrutural abaixo:

Quem cria e mantém a Definition of Done?

Uma dúvida comum é: de onde vem a Definition of Done? O Scrum Guide estabelece uma hierarquia clara de governança:

1. Padrão Organizacional (Herança Corporativa): Se a organização possui padrões corporativos globais de qualidade, segurança da informação (ISO 27001, SOC 2, LGPD) ou diretrizes de engenharia de software, a DoD de cada Scrum Team deve adotar esses padrões como linha de base mínima obrigatória. O time não tem a permissão de afrouxar regras corporativas de segurança;
2. Criação Autônoma pelo Scrum Team: Se a organização não possuir diretrizes formais, é dever de todo o Scrum Team (e não apenas do Scrum Master ou do PO) redigir, acordar e publicar uma Definition of Done adequada ao produto e à tecnologia utilizada;
3. Múltiplos Times no Mesmo Produto (Scrum Escalado): Se quatro equipes trabalham simultaneamente no mesmo produto (cenário comum em grandes empresas e no framework Scrum de Scrums do SBOK), todos os times devem compartilhar a mesma Definition of Done de base para garantir que os incrementos parciais se integrem perfeitamente sem quebrar o sistema consolidado.

Anatomia de uma Definition of Done Profissional (Checklist em 5 Camadas)

Uma DoD eficiente não é um parágrafo genérico de intenções; é uma lista de verificação (checklist) auditável e binária (ou o item cumpre, ou não cumpre). Abaixo está o modelo de referência em cinco camadas consolidado nas melhores empresas de tecnologia:

Camada 1: Excelência de Código e Arquitetura

• O código foi escrito em conformidade estrita com o style guide oficial do repositório (ex: ESLint, Prettier, SonarQube);
• Não foram introduzidas vulnerabilidades de segurança de severidade alta ou crítica identificadas na análise estática (SAST);
• Passou por Code Review obrigatório (Pull Request) aprovado por pelo menos um desenvolvedor par antes do merge;
• Débitos técnicos ou gambiarras temporárias foram expressamente rejeitados na revisão por pares.

Camada 2: Pirâmide de Testes Automatizados

• Testes unitários cobrem todas as novas regras de negócio críticas (cobertura mínima de 80% no módulo modificado);
• Testes de integração entre serviços e banco de dados rodaram e passaram 100% sem falhas;
• Testes de regressão automatizados confirmam que nenhuma funcionalidade antiga do produto foi quebrada;
• Cenários felizes e de exceção dos Critérios de Aceite foram validados manualmente ou via automação e2e (Cypress / Playwright).

Camada 3: Infraestrutura, Integração Contínua e Deploy (DevOps)

• A branch de feature foi integrada à branch principal (main/develop) sem conflitos;
• O pipeline de Integração Contínua (CI) compilou o pacote de software e gerou os artefatos com sucesso;
• As migrações de banco de dados (migrations) foram executadas e validadas com scripts de rollback testados;
• O incremento foi implantado com sucesso no ambiente de Staging (Homologação) com monitoramento ativo.

Camada 4: Segurança, Privacidade e Conformidade Legal

• Nenhum dado pessoal sensível de usuários foi exposto em logs públicos do servidor (em conformidade com a LGPD);
• Todas as novas chamadas de API exigem autenticação segura por token criptografado (JWT/OAuth2);
• Variáveis de ambiente, senhas e chaves de API estão armazenadas em cofres seguros (Secrets Manager), sem credenciais hardcoded no repositório.

Camada 5: Documentação e Aceite de Negócio

• Documentação da API atualizada no padrão Swagger / OpenAPI para os times integradores;
• Notas de lançamento (Release Notes) rascunhadas para comunicação aos clientes e suporte;
• Demonstrado e aceito funcionalmente pelo Product Owner antes da sessão formal de Sprint Review.

O que fazer quando uma história não cumpre a Definition of Done?

Imagine o seguinte cenário: na última quinta-feira da Sprint, o desenvolvedor concluiu a codificação de uma história de checkout. No entanto, ele não escreveu os testes automatizados exigidos e o pipeline de homologação falhou. Na sexta-feira pela manhã acontece a Sprint Review. O que o time deve fazer?

O Scrum Guide é categórico e não deixa margem para interpretações lenientes:

Se um item não atender à Definition of Done, ele não pode ser apresentado na Sprint Review como pronto e não pode ser liberado em produção. O item retorna imediatamente para o Product Backlog.

Isso acarreta três consequências formais:

1. Zero Pontos Contabilizados: O time não ganha "pontos proporcionais" na velocidade da Sprint. Não existe pontuar 5 pontos de uma história de 8 pontos. O valor atribuído na métrica de velocidade é rigorosamente zero;
2. Reavaliação pelo Product Owner: O PO tem a prerrogativa de reavaliar o item no próximo planejamento. Ele pode priorizá-lo para a Sprint seguinte (onde exigirá apenas o esforço residual para cumprir a DoD) ou rebaixar sua prioridade se outra necessidade de negócio surgiu;
3. Discussão na Retrospectiva: O Scrum Master deve levar a falha para a Sprint Retrospective. Por que o item não cumpriu a DoD? O time calculou mal a capacidade? Houve gargalo no ambiente? A análise da causa raiz impede a reincidência.

A DoD em projetos fora do desenvolvimento de software

O Scrum hoje é adotado com grande sucesso em agências de marketing, engenharia consultiva, recursos humanos e departamentos jurídicos. Nesses contextos, a DoD continua sendo o baluarte da qualidade:

Como elevar a barra: a DoD evolutiva na Retrospectiva

Uma equipe ágil madura trata a Definition of Done como um documento vivo. O conceito de "Elevação da Barra de Qualidade" (Step-Up DoD) preconiza que o checklist deve ser revisado periodicamente na Sprint Retrospective:

• Fase 1 (Time Iniciante): O checklist foca no básico: compilar sem erros, passar por revisão por pares e ser testado manualmente pelo PO;
• Fase 2 (Time Intermediário): Adiciona automação de testes unitários com cobertura mínima de 70% e deploy automatizado em homologação;
• Fase 3 (Time Avançado): Inclui testes de carga e desempenho, análise estática de vulnerabilidades e testes automatizados de acessibilidade digital (WCAG);
• Fase 4 (Excelência Operacional): Deploy contínuo em produção com feature flags, telemetria de negócio e rollback automatizado em caso de anomalia.

Aviso importante: A DoD pode — e deve — se tornar mais rigorosa ao longo do tempo. No entanto, ela nunca deve ser afrouxada para "bater meta de entrega" em momentos de pressão corporativa.

Os 6 maiores erros com a Definition of Done

1. DoD "Flexível" sob Pressão: Permitir que itens sem testes subam para produção porque "a diretoria precisa entregar nesta sexta-feira". Esse afrouxamento destrói a cultura de qualidade e explode em incidentes no final de semana.
2. DoD Inatingível que Paralisa a Equipe: Criar uma lista com 40 requisitos burocráticos impossíveis de serem cumpridos em um Sprint de duas semanas. A DoD deve ser desafiadora, mas realisticamente alcançável.
3. Confundir DoD com Critérios de Aceite: Achar que cumprir os critérios de negócio da história dispensa o cumprimento do checklist de engenharia e segurança.
4. Falta de Visibilidade Pública: Deixar o checklist guardado em um PDF que ninguém consulta. A DoD deve estar fixada na parede da sala física ou nos templates de Pull Request do GitHub/GitLab.
5. Não envolver os Developers na criação: Um gestor tradicional impor uma DoD técnica sem ouvir as pessoas que vão implementá-la, gerando resistência velada.
6. Não auditar a DoD nas demonstrações: O Product Owner aceitar itens na Sprint Review sem verificar se os testes automatizados e o checklist técnico foram de fato executados.

Perguntas Frequentes sobre a Definition of Done