O que é Definition of Done?
Em português: Definição de Pronto · Também conhecido como: DoD, Definição de Pronto, Definition of Output Done, critério de pronto
A Definition of Done é o padrão de qualidade que todo item precisa cumprir para ser considerado pronto no Scrum. Sem ela, "pronto" vira opinião.
A Definition of Done (DoD), ou Definição de Pronto, é a descrição formal do estado que o Incremento precisa atingir para cumprir os padrões de qualidade exigidos pelo produto. Ela vale para todos os itens do Product Backlog: um item só vira parte do Incremento, e só pode ser liberado ou apresentado na Sprint Review, quando cumpre a DoD.
Origem
A ideia de "pronto" acompanha o Scrum desde cedo. Ken Schwaber já usa a expressão, de passagem, em *Agile Project Management with Scrum* (2004), e o primeiro Scrum Guide, publicado por ele e Jeff Sutherland em 2010, já trazia uma seção sobre o tema.
A versão de 2020 do Scrum Guide mudou o status da DoD. Ela virou o compromisso do Incremento, assim como a Meta do Produto é o compromisso do Product Backlog e a Meta da Sprint, o do Sprint Backlog.
Em junho de 2025, o Scrum Guide Expansion Pack, complemento opcional de Ralph Jocham, John Coleman e Jeff Sutherland, rebatizou a DoD de Definition of Output Done e criou a Definition of Outcome Done, que trata do resultado gerado pelo produto. A referência oficial continua sendo o Scrum Guide 2020.
Fonte primária: The Scrum Guide (2020)
Na prática
Pensa no checklist que o piloto repassa antes de decolar. Não importa o destino: os itens são os mesmos em todo voo, e ninguém pula um porque está atrasado. A DoD é isso para o time: um checklist único, que vale para todo item e não se negocia no fim da Sprint.
O que acontece quando falta
Sem DoD explícita, "pronto" vira opinião. Cada um usa a própria régua, e o time entrega coisas que parecem funcionar mas não estão testadas, integradas ou em produção.
A conta chega depois. A dívida técnica cresce, o retrabalho come as Sprints seguintes e as métricas mentem: o burnup sobe com itens que não estão prontos, o cycle time parece curto porque o relógio parou antes da hora. O negócio acha que o time está rápido até o lançamento chegar com bugs, passos manuais e a sensação de que cada release é um milagre.
Como a Definition of Done funciona no Scrum
Pensa no checklist que o piloto repassa antes de decolar. Não importa o destino: os itens são os mesmos em todo voo, e ninguém pula um porque está atrasado. A DoD é isso para o time: um checklist único, que vale para todo item e não se negocia no fim da Sprint.
Quem cria. Se a organização tem um padrão de qualidade (segurança, compliance, acessibilidade), ele é o mínimo para todos os times, que podem acrescentar o que fizer sentido. Se não existe padrão, o Time Scrum cria uma DoD adequada ao produto. Quando vários times trabalham no mesmo produto, eles definem juntos e seguem a mesma DoD. Quem precisa cumprir a DoD são os Desenvolvedores.
Onde ela aparece no ciclo:
- Sprint Planning: a DoD precisa existir antes da Planning, porque ela diz quanto trabalho cada item exige de verdade. Dois dias de código podem virar cinco quando a DoD pede teste automatizado, revisão e deploy. - Durante a Sprint: um item só passa para "pronto" quando cumpre todos os itens da DoD. Nesse momento nasce um Incremento. - Sprint Review: só é apresentado o que cumpre a DoD. O que não cumpre volta para o Product Backlog, sem "quase pronto" e sem "90% feito". - Retrospectiva: é onde o time inspeciona a própria DoD e decide o que endurecer.
E cumprir a DoD não obriga ninguém a esperar a Review: um item pronto no terceiro dia pode ir para o cliente no terceiro dia. Liberar é decisão de negócio do Product Owner.
Exemplo de Definition of Done: do "pronto, só falta" à entrega de verdade
Imagine um time que cuida do app de uma fintech, com Sprints de duas semanas. Na Review, ele mostra 8 itens "prontos". Só que 5 ainda precisam passar pelo QA, 2 dependem de um script que o time de banco roda uma vez por semana, e 1 espera a revisão de segurança. Nenhum item chegou ao cliente, e a Sprint seguinte começa pagando o "só falta" da anterior.
O time passa a usar uma DoD honesta: só conta como pronto o item que passou por testes, pelo script de banco e pela revisão de segurança, ou seja, que pode ir para o cliente sem "só falta". Para isso, começa menos itens em paralelo e trabalha junto para terminar cada um. Na Sprint seguinte, o número de itens "prontos" cai de 8 para 3. Parece pior, mas esses 3 estão na mão do cliente, e as dependências externas, agora visíveis, viram impedimentos que o Scrum Master ajuda a remover junto com a organização. Em poucas Sprints, o time traz para dentro os testes e o script de banco, e o número de itens realmente prontos volta a subir, sem baixar a qualidade.
Veja como uma DoD pode ficar em três contextos diferentes.
Time de software:
- Código versionado e revisado por outra pessoa do time - Zero falhas nos testes automatizados do pipeline - Cobertura de testes nas regras de negócio igual ou maior que o combinado pelo time - Zero vulnerabilidades de nível crítico ou alto no scan de segurança - Funcionando no ambiente de produção, com a nova funcionalidade desligada ou ligada por feature flag
Time de produto financeiro, fora da tecnologia (exemplo do blog da K21):
- Manual de serviços atualizado com a mudança - Novos contratos referenciando as alterações - Avisos enviados aos clientes impactados - Prazo exigido pela legislação respeitado
Time de marketing:
- Peça revisada pelo jurídico - Links com parâmetros de rastreamento configurados - Métrica de sucesso da campanha definida e visível no painel - Versão acessível publicada (texto alternativo nas imagens, legenda nos vídeos)
Repara que nenhum item diz o que a funcionalidade faz. Isso é papel dos critérios de aceitação. A DoD trata de como tudo é construído e entregue.
Como criar a Definition of Done do seu time
Comece pelo cliente
Pergunte: "o que precisa acontecer para esse item chegar ao cliente sem nenhum trabalho extra?". A resposta é o ponto de chegada da DoD.
Liste todo o "só falta"
Anote tudo o que acontece depois que o time diz "pronto": testes de outro time, aprovação de segurança, script de banco, deploy. Cada "só falta" é um pedaço da DoD que ficou fora dela.
Separe o que o time já garante do que depende de fora
O que o time garante dentro da Sprint entra na DoD agora. O que depende de outras áreas fica visível no quadro e vira plano de melhoria. DoD curta e honesta vale mais que lista bonita que ninguém cumpre.
Respeite o mínimo da organização
Padrões de segurança, compliance ou acessibilidade entram como piso. Em cima deles, o time acrescenta o que faz sentido para o produto.
Escreva itens verificáveis
Cada item precisa ter resposta sim ou não. "Código testado" gera discussão. "Zero falhas nos testes automatizados do pipeline" não gera.
Deixe visível e use na Planning
A DoD fica ao lado do quadro e entra no planejamento de cada item. Se ela pede teste de carga, essa tarefa está no Sprint Backlog desde o primeiro dia.
Evolua na Retrospectiva
Toda vez que um bug escapar para produção, pergunte: qual item da DoD teria pegado isso? A resposta costuma ser o próximo item a entrar. DoD boa endurece com o tempo, nunca afrouxa para fechar Sprint.
Definition of Done vs Definition of Ready vs critérios de aceitação
| Definition of Done | Definition of Ready | Critérios de aceitação | |
|---|---|---|---|
| Pergunta que responde | O item está pronto para ser entregue? | O item está preparado para entrar na Sprint? | O item faz o que o cliente precisa? |
| Vale para | Todos os itens (uma DoD por produto) | Todos os itens candidatos à Sprint | Um item específico (cada item tem os seus) |
| Está no Scrum Guide? | Sim, é o compromisso do Incremento | Não, é prática complementar | Não, é prática complementar |
| Foco | Qualidade de construção e entrega | Entendimento e preparação | Comportamento esperado pelo cliente |
| Exemplo | Zero falhas nos testes automatizados | História com critérios de aceitação escritos | Cliente com score abaixo de 70 tem o empréstimo negado |
| Quando é usada | Planning, durante a Sprint e na Review | Refinamento e Planning | Refinamento, desenvolvimento e testes |
Um jeito simples de lembrar: critérios de aceitação dizem se o item faz a coisa certa. A DoD diz se ele foi feito do jeito certo. Um item só está pronto quando cumpre os dois.
A Definition of Ready é outra conversa: ela evita puxar para a Sprint um item que ninguém entendeu. Só cuidado para não virar portão burocrático. A DoR existe para melhorar a conversa no refinamento, não para barrar trabalho.
Erros comuns com a Definition of Done
- "Pronto, só falta testar." A DoD para no código e deixa teste, integração e deploy para outros times. Cada passagem de bastão cai na fila de alguém com outras prioridades, e o atraso se acumula.
- Sprint de testes. Criar Sprints só para testar ou "estabilizar" o que a DoD deveria cobrir. Isso esconde o problema, cria refluxo e reforça o "nós contra eles" dentro do time.
- DoD de enfeite. Lista caprichada que ninguém cumpre é pior que lista curta que todo mundo cumpre. Ela destrói a transparência que a DoD deveria garantir.
- Só de cima para baixo. Regras da organização devem entrar na DoD, mas não podem ser as únicas. Sem os itens que o próprio time considera essenciais, a DoD vira burocracia.
- Afrouxar no fim da Sprint. Baixar a régua para "fechar" itens. Item que não cumpre a DoD volta para o Product Backlog, sem exceção.
Visão K21
O que a gente aprendeu na prática sobre a Definition of Done
A DoD de verdade termina no cliente. Como o Avelino Ferreira Gomes Filho mostra em "Definition of Done? Está pronto, só falta testar!", a DoD deveria cobrir todo o trabalho necessário para que a única coisa entre o time e o cliente seja uma decisão de negócio. Aprovação da diretoria, manual do usuário, teste de segurança: se é exigido antes de ir para o cliente, faz parte da DoD.
Sem teste automatizado, a DoD fica míope. Quando toda Sprint precisa de uma rodada manual de "testar tudo para ver se nada quebrou", o pronto nunca é pronto de verdade, como mostra o post "Testes Automatizados: o que a falta deles pode causar?", do Paulo Silva.
Review não é banca de aprovação. O Marcos Garrido escreveu em "Product Owner surpreso na Review? E agora?" que, se a DoD foi construída em conjunto, o PO não tem por que fazer uma segunda conferência na Review. A Review serve para coletar feedback dos stakeholders, não para aprovar ou rejeitar o trabalho do time.
Em fluxo contínuo, a DoD se espalha pelo quadro. Com Kanban, a K21 usa a Definição de Transição (DoT): um pequeno checklist em cada coluna do quadro. As DoTs antes do ponto de comprometimento somam a Definition of Ready, e as de depois somam a DoD. O post "Qual a diferença entre Definição de Preparado, Pronto e Critérios de Aceitação?" mostra o quadro completo.
Baseado nos posts: Definition of Done? Está pronto, só falta testar!; Testes Automatizados – O que a falta deles pode causar?; Product Owner surpreso na Review? E agora?; Qual a diferença entre Definição de Preparado, Pronto e Critérios de Aceitação?
Para se aprofundar
No blog da K21
- Definition of Done? Está pronto, só falta testar!
Mostra por que o "pronto, só falta testar" trava a entrega e como sair dele.
- Qual a diferença entre critérios de aceitação e Definição de Pronto?
Exemplo completo, com BDD, de critérios de aceitação e DoD lado a lado.
- Qual a diferença entre Definição de Preparado, Pronto e Critérios de Aceitação?
DoR, DoD, DoT e critérios de aceitação explicados em um só lugar.
- Product Owner surpreso na Review? E agora?
Por que o Product Owner não deveria "aprovar" itens na Sprint Review.
- Scrum Guide Expansion Pack 2025: Tudo sobre as Novas Diretrizes do Scrum
O que muda com a Definition of Output Done e a Definition of Outcome Done.
Fontes primárias
- The Scrum Guide, Ken Schwaber e Jeff Sutherland (2020)
- Scrum Guide Expansion Pack, Ralph Jocham, John Coleman e Jeff Sutherland (2025)
- Agile Project Management with Scrum, Ken Schwaber (2004)
Termos relacionados
Perguntas frequentes
Quem define a Definition of Done?
Se a organização tem um padrão de qualidade, ele é o mínimo para todos os times. Se não tem, o Time Scrum cria a DoD do produto. Os Desenvolvedores devem cumpri-la, e times no mesmo produto compartilham uma única DoD.
Qual a diferença entre Definition of Done e critérios de aceitação?
A DoD vale para todos os itens e trata da qualidade de construção e entrega. Os critérios de aceitação são de cada item e descrevem o comportamento que o cliente espera. O item só está pronto quando cumpre os dois.
A Definition of Done pode mudar?
Pode e deve, geralmente na Retrospectiva, quando o time percebe um problema de qualidade ou ganha uma capacidade nova, como testes automatizados. A DoD tende a ficar mais exigente com o tempo. O que não vale é afrouxá-la no meio da Sprint para fechar itens.
O que acontece com um item que não cumpre a DoD no fim da Sprint?
Não é liberado nem apresentado na Sprint Review. Volta para o Product Backlog, e o Product Owner decide quando retomá-lo. Não existe "quase pronto" no Scrum.
Preciso esperar a Sprint Review para entregar um item pronto?
Não. Um item que cumpre a DoD pode ser entregue a qualquer momento da Sprint. A Review serve para inspecionar o Incremento e coletar feedback, não é portão de liberação. Liberar é decisão de negócio do Product Owner.
O que é Definition of Output Done?
É o nome que o Scrum Guide Expansion Pack, de 2025, dá à Definition of Done. O complemento também cria a Definition of Outcome Done, com as evidências de que o produto gerou o resultado esperado. Uma trata da qualidade da entrega, a outra do valor gerado.
