Definition of Done: Guia Completo com Exemplos e Checklist

Por Abhay Talreja

28/12/2025

Meu último artigo - Empirical Process Control - The Key to Agile Success

A Definition of Done (DoD) e um compromisso formal em Scrum e Agile que estabelece os criterios de qualidade que cada item do Product Backlog e Increment deve cumprir antes de ser considerado completo. Nao e apenas uma checklist - e um entendimento compartilhado entre todo o Scrum Team sobre o que significa "done", criando transparencia e garantindo Increments potencialmente entregaveis.

Caracteristicas principais: A Definition of Done se aplica universalmente a TODO o trabalho (diferente dos Acceptance Criteria que variam por story), evolui conforme as capacidades do time amadurecem, e e inegociavel - trabalho que nao cumpre a DoD nao pode ser liberado. Tipicamente inclui revisao de codigo, testes automatizados com limites de cobertura especificos, atualizacoes de documentacao, scans de seguranca e verificacao de deployment.

Distincao critica: A Definition of Done define padroes de QUALIDADE (ex., "codigo revisado," "tests >80% cobertura"), enquanto Acceptance Criteria define requisitos FUNCIONAIS (ex., "o usuario pode fazer login com email"). Ambos devem ser cumpridos para que o trabalho esteja realmente Done.

Resposta Rapida: Definition of Done em um Olhar

O Que Voce Aprendera Neste Guia

Neste guia completo, voce descobrira:

• Os Fundamentos: O que realmente significa Definition of Done em Scrum e por que e um compromisso, nao apenas uma checklist
• DoD vs Acceptance Criteria: Distincoes claras com comparacoes lado a lado e exemplos praticos mostrando como ambos devem ser cumpridos
• Checklists Especificos por Industria: Exemplos de DoD prontos para usar para 6 industrias (SaaS, Saude, Financas, E-commerce, Mobile, DevOps)
• A Hierarquia de Tres Niveis: Como estruturar DoD em nivel de Feature, Sprint e Release com frameworks de decisao
• Jornada de Maturidade: Fortalecimento progressivo desde DoD Basica (times novos) ate Intermediaria e Avancada (times de alto desempenho)
• Erros Comuns: 8 anti-padroes criticos que times cometem com DoD e exatamente como corrigi-los
• Estrategia de Evolucao: Guia passo a passo para melhorar incrementalmente DoD sem sobrecarregar o time
• Implementacao Pratica: Processo de criacao colaborativa, estrategias de visibilidade e tecnicas de aplicacao

Por Que a Definition of Done Importa Hoje

A Definition of Done nao e apenas outra formalidade do Scrum - e o guardiao de qualidade que previne o acumulo de divida tecnica e garante que cada Sprint entregue Increments potencialmente entregaveis. Este compromisso critico permite que os times:

• Eliminem a ambiguidade de qualidade atraves de padroes explicitos e mensuraveis que todos entendem
• Previnem a expansao de escopo definindo claramente quando o trabalho esta completo vs. quando ainda esta em progresso
• Habilitem releases previsiveis porque "done" significa genuinamente liberavel, nao "quase done"
• Apoiem times distribuidos com verificacao automatizada reduzindo as necessidades de comunicacao sincrona
• Escala consistentemente entre multiplos times trabalhando no mesmo produto com padroes compartilhados

Seja voce estabelecendo DoD para um novo time Scrum, fortalecendo DoD para um time em maturacao, ou garantindo cumprimento em industrias reguladas (saude, financas, governo), este guia fornece frameworks comprovados para o sucesso.

Vamos explorar como criar, implementar e evoluir uma Definition of Done que transforme as capacidades de qualidade e entrega do seu time.

O Que e Doneness?

Em Scrum, "doneness" se refere ao estado de completude de um Product Backlog Item (PBI) ou um Increment.

Indica que o trabalho foi terminado a um nivel de qualidade e completude que e aceitavel para o Scrum Team e os stakeholders.

Para garantir um entendimento compartilhado de quando um PBI ou Increment e considerado completo, os Scrum Teams usam a Definition of Done.

Definition of Done

A Definition of Done (DoD) e um entendimento compartilhado entre os membros do Scrum Team dos criterios que devem ser cumpridos para que um PBI ou Increment seja considerado completo.

Estabelece um conjunto claro e consistente de expectativas, garantindo que todos no time saibam o que e necessario para terminar uma tarefa com sucesso.

Enquanto as especificidades podem variar de uma organizacao para outra, uma DoD tipica abrange items chave como:

• O codigo esta peer-reviewed: Garantindo que o codigo seja examinado por pares para qualidade e precisao.
• O codigo esta checked in: Fazendo commit do codigo no controle de versao para acesso do time.
• O codigo esta deployed em um ambiente de teste: Tornando o codigo disponivel para testing.
• O codigo/feature passa regression testing: Verificando que as mudancas nao quebram funcionalidade existente.
• O codigo/feature passa smoke testing: Realizando testes basicos para garantir que o feature funcione como pretendido.
• O codigo esta documentado: Criando documentacao completa para ajudar na compreensao e manutencao futura.
• A documentacao de ajuda esta atualizada: Garantindo que a documentacao orientada ao usuario seja precisa e completa.
• O feature esta aprovado pelos stakeholders: Obtendo aprovacao de stakeholders relevantes para a preparacao do feature.

Estes checkpoints coletivamente servem como guardiao, distinguindo entre trabalho "em progresso" e aquele que esta genuinamente "done."

Atuam como uma rede de seguranca para manter qualidade e completude ao longo do processo de desenvolvimento.

O Guia Scrum Decifrado

Segundo o Guia Scrum, a Definition of Done serve como um blueprint formal do estado que um Increment deve alcancar para cumprir com os padroes de qualidade requeridos para o produto.

Uma vez que os criterios da Definition of Done sao cumpridos, o Increment ganha o cobicado status de "Done" e esta pronto para entrega.

Os Objetivos da Definition of Done

Construindo Consenso sobre Qualidade

Um dos objetivos principais da DoD e fomentar um entendimento comum dentro do time sobre qualidade e completude.

Quando todos estao de acordo sobre o que significa 'done', elimina confusao e agiliza o processo de desenvolvimento.

Uma Checklist Confiavel

DoD atua como uma checklist confiavel contra a qual se verificam as User Stories ou Product Backlog Items.

Isso garante que nada escape, e cada aspecto de uma tarefa seja examinado meticulosamente.

Garantindo Increments de Alta Qualidade

Em ultima instancia, o objetivo primordial da DoD e garantir que o increment enviado ao final do Sprint seja de alta qualidade.

Esta qualidade deve ser claramente entendida por todos os membros do time, stakeholders e qualquer pessoa envolvida no projeto.

Beneficios da Definition of Done

Ter uma Definition of Done bem definida e essencial no desenvolvimento Agile por varias razoes:

• Fornece clareza e consistencia: Os membros do time e stakeholders tem um claro entendimento do que e esperado para cada tarefa completada.
• Melhora a qualidade: Ao definir padroes de qualidade e requisitos de testing, ajuda a entregar um produto de maior qualidade.
• Reduz mal-entendidos: Minimiza o risco de ma comunicacao e garante que todos estejam na mesma pagina quanto a completude do projeto.
• Ajuda na tomada de decisoes: Ajuda o time a decidir quando uma tarefa ou feature esta pronta para release, agilizando o processo de desenvolvimento.
• Melhora a transparencia: Os stakeholders podem acompanhar o progresso mais efetivamente, sabendo que "done" significa que todo o trabalho necessario esta completo.

Por Onde Comecar o Processo de Definicao

Definir a DoD deve ser um esforco colaborativo que envolva stakeholders e aqueles responsaveis pelo trabalho real.

Seja que comece com brainstorming ou um framework proposto pelo time tecnico, amplas oportunidades para feedback e apoio unanime para a DoD final sao essenciais.

Atribuir propriedade a cada criterio ajuda a resolver disputas e manter consistencia.

Em aderencia ao principio Agile de simplicidade, a DoD deve ser concisa. Seu proposito e garantir qualidade consistente, nao criar obstaculos burocraticos.

Complicar demais a DoD pode impedir o progresso em vez de facilita-lo.

Criando uma Definition of Done Eficaz

Para criar uma Definition of Done eficaz para seu Scrum Team, siga estes passos:

1. Colaborar: Envolva todo o Scrum Team na criacao da DoD, garantindo que a perspectiva de todos seja considerada, e um entendimento compartilhado seja estabelecido.

2. Definir Criterios: Identifique os criterios que devem ser cumpridos para que um PBI ou Increment seja considerado completo. Inclua aspectos como funcionalidade, qualidade, desempenho, documentacao e cumprimento.

3. Mante-la Visivel: Torne a DoD facilmente acessivel e visivel para todo o Scrum Team, garantindo que os membros do time estejam sempre cientes das expectativas.

4. Revisar e Atualizar: Revise e atualize regularmente a DoD baseando-se nos aprendizados, experiencias e requisitos em mudanca do Scrum Team.

Tres Perguntas Criticas

Para determinar onde pertence uma atividade na hierarquia de DoD, tres perguntas devem guiar seu processo de tomada de decisao:

• Podemos fazer esta atividade para cada feature?
• Se nao, podemos fazer esta atividade para cada sprint?
• Se nao, torna-se imperativo incluir esta atividade para nosso release.

Definition of Done vs Acceptance Criteria: Diferencas Chave

Muitos times confundem Definition of Done com Acceptance Criteria - mas servem propositos diferentes e devem trabalhar juntas.

Definition of Done (DoD)

Escopo: Se aplica a TODO o trabalho em TODOS os Product Backlog items

Proposito: Define padroes de qualidade e praticas tecnicas

Quem Define: Scrum Team colaborativamente (frequentemente herdada de padroes organizacionais)

Exemplos de Items de DoD:

• Codigo revisado por pelo menos um par
• Unit tests escritos e passando (>80% cobertura)
• Integration tests passando
• Sem bugs criticos ou de alta prioridade
• Documentacao atualizada
• Scan de seguranca completado
• Benchmarks de desempenho cumpridos

Ponto Chave: DoD e consistente entre todos os features - cada item deve cumprir a mesma barra de qualidade.

Acceptance Criteria (AC)

Escopo: Unico para cada Product Backlog item ou user story especifico

Proposito: Define requisitos funcionais e logica de negocio

Quem Define: Product Owner (com input dos Developers sobre viabilidade)

Exemplo de AC para Story "Login de Usuario":

• Usuario pode fazer login com email e senha
• Credenciais invalidas mostram mensagem de erro
• Login bem-sucedido redireciona para o dashboard
• Link "Esqueci senha" envia email de reset
• Login persiste 30 dias com "Lembrar-me"

Ponto Chave: AC varia por story - cada feature tem requisitos funcionais unicos.

Trabalhando Juntas

Ambas devem ser cumpridas: O trabalho so esta "Done" quando cumpre tanto a Definition of Done (qualidade) quanto os Acceptance Criteria (funcionalidade).

Exemplos de Definition of Done por Industria

Diferentes industrias requerem diferentes items de DoD baseados em cumprimento, seguranca e requisitos especificos do dominio.

Software-as-a-Service (SaaS)

✓ Codigo revisado e aprovado
✓ Unit tests passando (minimo 80% cobertura)
✓ Integration tests passando
✓ Documentacao de API atualizada
✓ Scan de vulnerabilidades de seguranca passou
✓ Performance testing completado (< 2s tempo de resposta)
✓ Feature flag configurado
✓ Monitoramento e alertas configurados
✓ Runbook de deployment atualizado
✓ Product Owner aprovou

Saude / Software Compativel com HIPAA

✓ Codigo revisado por developer senior
✓ Todos os tests passando (unit, integration, E2E)
✓ Checklist de cumprimento HIPAA completado
✓ Criptografia de dados PHI verificada
✓ Audit logging implementado
✓ Controles de acesso testados
✓ Revisao de seguranca passou
✓ Avaliacao de impacto de privacidade completada
✓ Documentacao atualizada (tecnica + usuario)
✓ Oficial de cumprimento aprovou

Servicos Financeiros / Banca

✓ Codigo revisado (revisao dual para caminhos criticos)
✓ Tests automatizados passando (>90% cobertura)
✓ Cumprimento PCI-DSS verificado
✓ Penetration testing completado
✓ Tests de integridade de transacoes passaram
✓ Procedimento de rollback documentado
✓ Regras de deteccao de fraude atualizadas
✓ Capacidade de relatorio regulatorio verificada
✓ Audit trail implementado
✓ Change Advisory Board aprovou

Plataforma E-Commerce

✓ Codigo peer-reviewed
✓ Unit + integration tests passando
✓ Cross-browser testing completado (Chrome, Safari, Firefox, Edge)
✓ Design responsivo movel verificado
✓ Tempo de carregamento de pagina < 3 segundos
✓ Analytics tracking implementado
✓ SEO meta tags adicionados
✓ Fluxo de carrinho e checkout testado
✓ Integracao de payment gateway testada
✓ User acceptance testing passou

Desenvolvimento de Apps Moveis

✓ Codigo revisado
✓ Unit tests passando (>75% cobertura)
✓ UI/UX coincide com specs de design
✓ Testado em iOS (ultima + 2 versoes anteriores)
✓ Testado em Android (ultima + 3 versoes anteriores)
✓ Padroes de acessibilidade cumpridos (WCAG 2.1 AA)
✓ Screenshots e descricoes de app store prontos
✓ Crash reporting configurado
✓ Analytics events rastreando corretamente
✓ Privacy policy e permissoes atualizados

DevOps / Infraestrutura

✓ Infrastructure as Code (IaC) peer-reviewed
✓ Tests automatizados passando
✓ Security groups e IAM policies revisadas
✓ Estimativa de custos completada
✓ Dashboards de monitoramento criados
✓ Alertas e runbooks documentados
✓ Disaster recovery testado
✓ Ticket de change management aprovado
✓ Deployment verificado em staging
✓ Procedimento de rollback documentado e testado

Os Tres Niveis de Definition of Done

Segundo Scrum Alliance e especialistas Agile, DoD pode existir em multiplos niveis - os times devem decidir conscientemente onde pertence cada atividade de qualidade.

Nivel 1: DoD a Nivel de Feature

Atividades realizadas para CADA Product Backlog item

✓ Codigo escrito seguindo padroes de codificacao ✓ Unit tests escritos e passando ✓ Codigo peer-reviewed ✓ Acceptance Criteria cumpridos ✓ Testing local completado

Pergunta: Podemos realisticamente fazer isso para cada feature individual?

Nivel 2: DoD a Nivel de Sprint

Atividades realizadas uma vez por Sprint para o Increment completo

✓ Integration testing entre todos os features do Sprint ✓ Suite de regression testing executada ✓ Performance testing completado ✓ Security scan executado ✓ Documentacao do Sprint consolidada ✓ Increment deployed em ambiente de staging

Pergunta: Se nao e viavel por feature, podemos fazer uma vez por Sprint?

Nivel 3: DoD a Nivel de Release

Atividades realizadas antes de liberar para producao

✓ User acceptance testing (UAT) com stakeholders ✓ Load testing sob condicoes similares a producao ✓ Penetration testing e auditoria de seguranca ✓ Revisao de cumprimento e sign-off ✓ Runbook de deployment para producao executado ✓ Materiais de marketing e release notes preparados ✓ Suporte ao cliente treinado nos novos features

Pergunta: Se nao e viavel por Sprint, devemos fazer antes do release?

Por Que Importam Multiplos Niveis

Realidade: Nem todas as atividades de qualidade podem ser feitas para cada feature. Exemplos:

• Full penetration testing nao pode acontecer para cada story - e uma atividade de nivel Release
• Integration testing entre todos os features acontece uma vez por Sprint, nao por feature
• Load testing com 10,000 usuarios concorrentes e proibitivamente caro por feature

Solucao: Seja explicito sobre em que nivel pertence cada atividade de DoD. Isso cria:

• Transparencia: Todos sabem quando as atividades acontecem
• Expectativas realistas: Os times nao prometem atividades impossiveis por feature
• Quality gates: As atividades criticas nao sao puladas - sao agendadas apropriadamente

Erros Comuns de Definition of Done (E Como Corrigi-los)

Erro 1: Confundir DoD com Acceptance Criteria

Problema: O time trata DoD como requisitos funcionais em vez de padroes de qualidade

Exemplo: DoD inclui "Usuario pode fazer login com email" (isso e Acceptance Criteria)

Correcao: DoD deve ser padroes tecnicos/de qualidade (ex., "Todos os features orientados ao usuario tem >80% cobertura de tests"), nao especificacoes funcionais

Erro 2: Criar uma DoD Impossivel

Problema: DoD inclui atividades que o time realmente nao pode completar cada Sprint

Exemplo: "Auditoria de seguranca completa por firma externa" (custa $50K, leva 3 semanas)

Correcao: Mover isso para DoD de nivel Release. DoD de Sprint poderia ser "Scan de seguranca automatizado passou"

Erro 3: DoD Muito Vaga

Problema: Declaracoes genericas que nao impulsionam acao

Exemplo: "O codigo deve ser de alta qualidade" ou "Testing completo"

Correcao: Seja especifico: "Codigo revisado por developer senior" e "Unit tests >80% cobertura, integration tests passando, smoke tests passaram"

Erro 4: Nunca Evoluir a DoD

Problema: O time usa a mesma DoD por anos apesar de ganhar capacidades

Exemplo: O time aprende automated testing mas DoD ainda diz "Apenas testing manual"

Correcao: Revisar DoD trimestralmente em Retrospectives. Conforme o time melhora, fortalecer DoD (ex., subir cobertura de tests de 70% → 80% → 90%)

Erro 5: Pular DoD Quando "Sob Pressao"

Problema: O time compromete DoD para cumprir Sprint Goal, acumulando divida tecnica

Exemplo: "Vamos pular code review desta vez - estamos atrasados"

Correcao: DoD e inegociavel. Se nao pode cumprir DoD, o trabalho NAO esta Done. Reduza escopo em vez de comprometer qualidade

Erro 6: Uma Pessoa Possui DoD

Problema: Apenas o Scrum Master ou tech lead define DoD sem input do time

Exemplo: Tech lead cria checklist de 20 items de DoD sem consultar os Developers

Correcao: Todo o Scrum Team colabora na DoD. Todos devem entende-la e comprometer-se com ela

Erro 7: Nao Mostrar DoD Visivelmente

Problema: DoD vive numa wiki que ninguem revisa

Exemplo: "Onde esta nossa DoD?" "Uh... em algum lugar no Confluence?"

Correcao: Tornar DoD visivel no seu board, em Sprint Planning, e durante Sprint Review

Erro 8: DoD Sem Propriedade

Problema: Items de DoD existem mas ninguem verifica cumprimento

Exemplo: DoD diz "Documentacao atualizada" mas ninguem verifica se aconteceu

Correcao: Atribuir propriedade clara para verificacao de cada item de DoD, ou torna-lo parte do checklist de code review

Como Evolui a Definition of Done: A Jornada de Maturidade

Grandes times nao comecam com DoD perfeita - a fortalecem ao longo do tempo conforme as capacidades melhoram.

Etapa 1: DoD Basica (Novos Scrum Teams)

DoD Tipica:

✓ Codigo escrito
✓ Codigo committed no controle de versao
✓ Testing manual basico completado
✓ Acceptance Criteria cumpridos

Caracteristicas:

• Minimo automated testing
• Alta dependencia de testing manual
• Verificacoes de qualidade basicas
• Foco em fazer o trabalho "funcional"

Foco de Melhoria: Introduzir automated unit testing e peer review

Etapa 2: DoD Intermediaria (Times em Maturacao)

DoD Tipica:

✓ Codigo revisado por par
✓ Unit tests escritos (>60% cobertura)
✓ Integration tests passando
✓ Acceptance Criteria cumpridos
✓ Deployed em ambiente de teste
✓ Documentacao basica atualizada

Caracteristicas:

• Automated testing emergindo
• Processo de code review estabelecido
• Pipeline CI/CD comecando
• Qualidade tornando-se sistematica

Foco de Melhoria: Aumentar cobertura de tests, adicionar automated deployment

Etapa 3: DoD Avancada (Times de Alto Desempenho)

DoD Tipica:

✓ Codigo revisado e aprovado
✓ Unit tests passando (>85% cobertura)
✓ Integration tests passando
✓ E2E tests passando
✓ Security scan passou
✓ Benchmarks de desempenho cumpridos (<2s resposta)
✓ Padroes de acessibilidade verificados (WCAG 2.1 AA)
✓ Documentacao atualizada (codigo + usuario)
✓ Feature flag configurado
✓ Monitoramento/alertas configurados
✓ Deployed automaticamente em staging
✓ Product Owner aprovou em staging

Caracteristicas:

• Automated testing abrangente
• Pipeline CI/CD completo
• Medidas de qualidade proativas
• "Potencialmente entregavel" realmente significa entregavel

Foco de Melhoria: Melhoria continua atraves de metricas e feedback

Como Fortalecer Sua DoD

Passo 1: Identificar Lacunas Atuais

Durante Sprint Retrospective, perguntar:

• Que problemas de qualidade escaparam apesar de cumprir DoD?
• Que divida tecnica estamos acumulando?
• O que causa retrabalho ou bugs em producao?

Passo 2: Adicionar Uma Melhoria de Cada Vez

Nao sobrecarregar o time. Fortalecer DoD incrementalmente:

• Sprint 1-3: Adicionar requisito de peer code review
• Sprint 4-6: Requerer unit tests para codigo novo (>50% cobertura)
• Sprint 7-9: Aumentar para >70% cobertura
• Sprint 10+: Adicionar requisito de integration testing

Passo 3: Investir em Construcao de Capacidades

DoD so pode melhorar se as capacidades do time melhoram:

• Precisa de maior cobertura de tests? Fornecer treinamento em TDD
• Precisa de melhor seguranca? Trazer especialista em seguranca para workshops
• Precisa de automated deployment? Investir em infraestrutura CI/CD

Passo 4: Medir e Adaptar

Rastrear metricas para validar melhorias de DoD:

• Taxa de defeitos escapados (bugs encontrados em producao)
• Tempo para corrigir problemas de producao
• Frequencia de deployment
• Tempo medio de recuperacao (MTTR)

Conclusao

A Definition of Done e crucial para manter transparencia, alinhar expectativas dos membros do time, e entregar um increment potencialmente liberavel ao final de cada sprint.

Vai alem da funcionalidade para afirmar a qualidade de um feature. Informada pela realidade, se adapta a varios niveis, fornecendo clareza, e fomentando comunicacao dentro do time e com stakeholders.

Ajuda a prevenir que trabalho incompleto ou de baixa qualidade seja considerado "done" e fornece uma guia clara de quando o trabalho de desenvolvimento esta verdadeiramente completo.

Entender a DoD e aplica-la efetivamente e uma jornada em direcao a entregar nao apenas software mas excelencia em cada linha de codigo.

Ao embarcar nesta jornada, lembre-se que a Definition of Done e uma ferramenta dinamica, sempre pronta para evoluir e guiar seu time para maiores alturas.

Continuar Lendo

Perguntas Frequentes (FAQs)