Definition of Done: Exemplos e Como Escrever uma

A Definition of Done (DoD) é um daqueles conceitos que parece óbvio até que a equipe entregue algo que quebrou em produção, passou sem revisão ou nunca foi documentado. A partir daí, torna-se urgente.

O que é uma Definition of Done (DoD)?

Uma Definition of Done é um checklist compartilhado e acordado de critérios que um item de trabalho deve satisfazer antes de a equipe considerá-lo completo. Não "quase pronto." Não "funciona na minha máquina." Realmente pronto.

A DoD se aplica a cada Increment de trabalho no mesmo nível: cada história de usuário, cada Sprint, cada release. Ela não é escrita por uma pessoa e apresentada de cima para baixo. É criada pela equipe em conjunto, publicada em um lugar visível e aplicada de forma consistente. Quando o trabalho atende a cada item da lista, está concluído. Quando não atende, não está.

Fatos relevantes: Definition of Done

• Equipes com uma DoD claramente documentada entregam 28% menos defeitos do que equipes sem uma, de acordo com pesquisa publicada no periódico Empirical Software Engineering (2018).
• O State of Agile Report 2023 (digital.ai) constatou que práticas inconsistentes e padrões pouco claros estão entre os cinco principais motivos pelos quais as transformações ágeis falham: a DoD aborda diretamente ambos.
• Um estudo de Capers Jones revelou que corrigir um defeito em produção custa 10 a 100 vezes mais do que detectá-lo durante o desenvolvimento; uma DoD que inclui requisitos de teste e revisão é uma das ferramentas de prevenção de defeitos de menor custo disponíveis.

Definition of Done vs. critérios de aceitação

Esses dois termos são constantemente confundidos, e a confusão causa problemas reais. Eles estão relacionados, mas cobrem terrenos diferentes.

Os critérios de aceitação respondem: esta funcionalidade faz o que deveria fazer? A DoD responde: a equipe fez tudo o que é necessário para chamar este Increment de entregável?

Uma história pode passar em todos os critérios de aceitação e ainda assim reprovar na DoD se, por exemplo, a documentação não foi atualizada ou o código não foi revisado. Ambas as verificações precisam passar.

Algumas equipes também usam uma Definition of Ready (DoR) no início do processo: um checklist de condições que um item de trabalho deve atender antes de a equipe puxá-lo para um Sprint. A DoD fecha o ciclo no final. Juntas, elas criam um limite de qualidade em torno de todo o ciclo do Sprint. Veja refinamento do Backlog para entender como a DoR se encaixa na preparação do Sprint.

Por que a Definition of Done importa

Sem uma DoD, "pronto" significa algo diferente para cada pessoa da equipe. O desenvolvedor considera uma funcionalidade pronta quando o código compila. O engenheiro de QA considera pronta quando os testes passam. O tech lead considera pronta quando foi revisada por código. O Product Owner considera pronta quando está implantada. Nenhum deles está errado. Mas se nunca chegam a um padrão único, a equipe continuará entregando trabalhos parcialmente concluídos de formas que ninguém antecipou.

Veja o que acontece na prática. Uma equipe sem DoD:

• Entrega código que funciona localmente, mas falha em staging porque as verificações de ambiente não faziam parte do checklist mental de ninguém
• Integra trabalho que foi "revisado" pela própria pessoa que o escreveu
• Acumula dívida de documentação porque ninguém registrou isso como requisito
• Passa metade da retrospectiva do sprint discutindo o que "pronto" realmente significa para as histórias que acabaram de concluir

Uma equipe com DoD:

• Tem um padrão compartilhado e inegociável que não depende de interpretação individual
• Detecta lacunas durante o Sprint, não após a implantação
• Reduz retrabalho porque todos conhecem os critérios de saída antes de começar
• Avança mais rápido porque há menos surpresas na revisão do sprint

A DoD também protege o product backlog de falsas conclusões. Quando uma história é marcada como pronta sem atender a todos os critérios, o trabalho real (as correções, a revisão, a documentação) fica enterrado em algum lugar do backlog e ressurge mais tarde como trabalho não planejado.

Níveis de conclusão

A maioria das equipes opera com três níveis de conclusão. Cada nível tem seu próprio checklist, e um checklist de nível superior normalmente inclui tudo do nível abaixo.

Conclusão no nível de história

Este é o checklist aplicado a histórias de usuário ou tarefas individuais. Ele cobre o trabalho específico necessário para entregar um Increment:

• Código escrito e auto-revisado
• Testes unitários escritos e passando
• Código revisado por pelo menos outro membro da equipe
• Critérios de aceitação atendidos e verificados
• Branch da funcionalidade integrada à branch principal (ou à branch de integração acordada)

Conclusão no nível de Sprint

Este checklist se aplica ao Increment completo do Sprint: a soma de todas as histórias concluídas no Sprint. Frequentemente adiciona critérios de integração e implantação:

• Todos os itens da DoD em nível de história atendidos para cada história incluída
• Testes de integração passando na build completa
• Implantado no ambiente de staging
• Meta do sprint alcançada ou explicitamente avaliada
• Notas de versão ou changelog atualizado

Conclusão no nível de release

Isso cobre tudo o que é necessário antes de o Increment chegar aos usuários em produção. É onde os critérios de conformidade, desempenho e aprovação normalmente ficam:

• Testes de ponta a ponta passando em um ambiente similar à produção
• Benchmarks de desempenho atendidos (tempo de carregamento, taxa de erro etc.)
• Verificação de segurança concluída sem nenhuma descoberta crítica
• Documentação atualizada e publicada
• Aprovação das partes interessadas obtida
• Plano de rollback documentado

Equipes que trabalham com sprint planning devem ter clareza sobre qual nível de conclusão se aplica à saída de cada Sprint. Nem todo Sprint termina em um release para produção, mas a equipe deve saber exatamente qual é a referência antes de começar.

Exemplos de Definition of Done

Aqui estão checklists concretos de DoD para três tipos comuns de equipes. Não são templates para copiar literalmente: são pontos de partida. A DoD da sua equipe deve refletir seus padrões, ferramentas e fluxo de trabalho reais.

Equipe de desenvolvimento de software (nível de história)

• Código escrito e compilado sem erros
• Testes unitários escritos para nova lógica, com pelo menos 80% de cobertura nos arquivos alterados
• Código revisado e aprovado por pelo menos outro desenvolvedor
• Todos os testes automatizados passando no pipeline de CI
• Nenhum novo erro de linting introduzido
• Funcionalidade implantada no ambiente de staging e testada com smoke test
• Critérios de aceitação verificados pelo desenvolvedor ou QA
• Novos APIs ou alterações de configuração documentados na wiki da equipe
• Feature flag ou toggle implementado se o trabalho não estiver pronto para rollout completo

Equipe de marketing e conteúdo (nível de história)

• Conteúdo escrito conforme a contagem de palavras e diretrizes de tom acordados
• Revisado por um segundo redator ou editor quanto à precisão e à voz da marca
• Checklist de SEO concluído (tag de título, meta description, palavra-chave alvo no H1)
• Todos os links internos verificados e funcionando
• Imagens otimizadas e texto alternativo adicionado
• Agendado ou publicado no CMS conforme o calendário de conteúdo
• Tarefas de distribuição concluídas (posts em redes sociais agendados, inclusão na newsletter confirmada)
• Rastreamento de análise confirmado (parâmetros UTM, tags de evento no lugar)

Equipe de design (nível de história)

• Design corresponde ao briefing aprovado ou aos requisitos da história de usuário
• Revisado pelo designer líder e pelas partes interessadas relevantes
• Diretrizes de acessibilidade verificadas (contraste de cores, tamanho de tipografia, fluxo de teclado para elementos interativos)
• Todos os estados documentados: padrão, hover, foco, erro, vazio, carregando
• Assets exportados nos formatos necessários e carregados na biblioteca de design compartilhada
• Notas de handoff escritas para a equipe de desenvolvimento
• Qualquer feedback pendente da revisão resolvido ou explicitamente adiado com justificativa

Como escrever uma Definition of Done

Etapa 1: Reúna a equipe

A DoD só funciona se todos acreditam nela. Isso significa criá-la juntos: desenvolvedores, designers, QA, Product Owners, quem quer que faça o trabalho. Um workshop de 60 minutos normalmente é suficiente para obter uma primeira versão. Não deixe o Scrum Master ou o líder da equipe escrevê-la sozinho e apresentá-la para "aprovação." A cocriação é o ponto central.

Etapa 2: Liste o que a conclusão realmente requer

Comece perguntando à equipe: "Pense no último trabalho que entregamos que voltou com um problema. Qual etapa foi pulada?" Trabalhe de trás para frente a partir das falhas para encontrar os itens do checklist que importam. Depois trabalhe para frente: como é a qualidade quando entregamos bem? O que nos envergonharia se esquecêssemos?

Agrupe os itens em categorias: qualidade do código, testes, documentação, implantação, revisão. Isso torna a DoD mais fácil de escanear durante o Sprint.

Etapa 3: Mantenha cada item verificável

Cada item da DoD deve ser comprovável: ou está feito ou não está. "A qualidade do código é boa" não é um item de DoD. "Código revisado e aprovado por pelo menos um membro da equipe diferente do autor" sim. O teste: você consegue apontar evidências de que este item foi concluído? Se sim, pertence à DoD. Se requer julgamento, transforme-o em uma diretriz ou divida-o em critérios mais específicos.

Etapa 4: Concorde e publique em lugar visível

Uma vez que a equipe tem um rascunho, obtenha acordo explícito. Não "sem objeções," mas adesão real. Publique a DoD em algum lugar que toda a equipe veja todo dia: o quadro do Sprint, a wiki da equipe, a descrição do canal no Slack. Não deve ser um documento enterrado em uma pasta que ninguém abre. Se a equipe não consegue vê-la, ela não será usada.

Etapa 5: Revise e evolua

A DoD não é permanente. Deve ser revisada na retrospectiva do sprint sempre que a equipe entregar algo que revelou uma lacuna. Quando a equipe adiciona uma nova ferramenta (como um scanner de segurança automatizado), adicione-a à DoD. Quando um item do checklist se torna tão automático que ninguém o pula, considere se ainda precisa ser escrito ou se já é apenas um hábito da equipe.

Uma DoD que nunca muda é perfeita (improvável) ou está sendo ignorada (mais provável).

Erros comuns

Torná-la muito longa. Uma DoD com 30 itens não é usada. Busque 8 a 12 itens que cubram suas lacunas reais de qualidade, não um ideal exaustivo. Se você não consegue recitar a DoD de memória depois de uma semana, ela é longa demais.

Escrevê-la no nível organizacional em vez do nível de equipe. Uma DoD repassada pela liderança cobre política, não prática. Cada equipe precisa de uma DoD que reflita seu fluxo de trabalho, ferramentas e padrões reais.

Tratá-la como aspiracional. Se a equipe não consegue realisticamente atender a cada item da DoD em um Sprint normal, a DoD é aspiracional, não operacional. Reduza-a ao que a equipe pode realmente se comprometer e eleve a régua gradualmente conforme a capacidade e as ferramentas melhoram.

Pulá-la durante períodos de pressão. "Vamos pular a documentação neste Sprint porque estamos com pouco tempo" é o momento em que a DoD para de significar qualquer coisa. Exceções parciais se acumulam em exceções consistentes. Se a DoD pode ser suspensa sob pressão, nunca foi um padrão real.

Esquecer os requisitos não funcionais. O comportamento funcional é coberto pelos critérios de aceitação. A DoD é onde vivem os padrões de desempenho, segurança, acessibilidade e documentação. Equipes que deixam esses fora da DoD entregam funcionalidades que funcionam, mas degradam o sistema ao longo do tempo.

Perguntas frequentes

Quem é o responsável pela Definition of Done?

A equipe a possui coletivamente. O Product Owner pode influenciá-la (ele se preocupa com a capacidade de release), e o Scrum Master pode facilitar sua criação e revisão. Mas no Scrum, os Desenvolvedores são os que se comprometem a atender à DoD para cada Increment. Ninguém pode alterá-la unilateralmente no meio de um Sprint.

Qual é a diferença entre uma Definition of Done e um checklist?

Uma DoD é um tipo de checklist, mas com um propósito específico e um contrato por trás. Um checklist é uma ferramenta. A DoD é um acordo de que cada Increment deve superar essa barra antes de a equipe chamá-lo de pronto. A distinção importa porque implica responsabilidade compartilhada e consequências: trabalho que não atende à DoD não é contabilizado em direção à meta do Sprint.

Toda equipe precisa de uma Definition of Done?

Sim, se a equipe entrega trabalho do qual outras pessoas dependem. A DoD é o mecanismo que faz "pronto" significar a mesma coisa para todos. Equipes sem uma desenvolvem padrões implícitos (que não são compartilhados nem aplicados) ou discutem sobre o conceito de "pronto" nos piores momentos, geralmente no final de um Sprint.

A Definition of Done pode ser diferente para tipos diferentes de trabalho?

Sim, com cautela. Muitas equipes têm uma DoD em nível de história e outra em nível de Sprint (como descrito na seção de níveis acima). Algumas equipes têm critérios ligeiramente diferentes para correções de bugs vs. novas funcionalidades. Mas cuidado com a fragmentação. Quanto mais exceções e casos especiais a DoD tiver, mais carga cognitiva ela cria e menos confiável ela é aplicada.

Como a Definition of Done se relaciona com story points?

Story points estimam esforço relativo. A DoD define padrões de qualidade. Eles estão conectados porque a DoD deve ser considerada nas estimativas: se atender à DoD para uma história leva 3 horas extras, esse tempo deve ser refletido na estimativa de story points, não tratado como sobrecarga que é ignorada quando a equipe está sob pressão. Quando as equipes subestimam histórias porque não estão considerando os requisitos da DoD, acabam exatamente no tipo de pressão que leva a atalhos na DoD.

---

Uma Definition of Done bem elaborada não desacelera uma equipe. Ela remove a ambiguidade que desacelera as equipes. Quando todos sabem exatamente o que "pronto" significa antes de começar, há menos surpresas, menos loops de retrabalho e menos discussões na revisão do sprint. Comece com algo simples, aplique de forma consistente e deixe-a evoluir junto com a equipe.

Leitura relacionada

• Product backlog
• Refinamento do Backlog
• User stories
• Story points
• Retrospectiva do sprint
• Sprint planning
• O que é Scrum?