Definition of Done: o que é "pronto" de verdade

O que é Definition of Done

Definition of Done (DoD, ou "definição de pronto") é a lista de condições que todo item de trabalho do time precisa cumprir para ser considerado pronto de verdade. Não é a descrição do que o item faz — é o padrão de qualidade que qualquer entrega precisa atingir antes de o time dizer "está feito". Testado, revisado por outra pessoa, publicado no ambiente certo, comunicado a quem precisava saber: cada time monta a sua lista, mas ela vale igualmente para todos os itens, sempre.

A DoD nasceu no Scrum, onde é um compromisso formal ligado ao incremento da sprint, mas a ideia serve para qualquer time que entrega trabalho — de engenharia a marketing, de RH a operações. O problema que ela resolve é universal: sem um acordo explícito, "pronto" significa uma coisa diferente para cada pessoa. Para quem fez, pronto é "terminei a minha parte". Para quem recebe, pronto é "posso usar isso agora, sem surpresas". A distância entre essas duas definições é onde mora o retrabalho, a entrega que volta, o cliente que reclama.

Em uma frase: a Definition of Done transforma "pronto" de opinião em contrato. Quando o item cumpre a lista, está pronto; quando não cumpre, não está — não existe "quase pronto", "pronto, só falta subir" ou "pronto do meu lado".

"Terminei" não é "está pronto"

Todo gestor já viveu esta cena. Na segunda-feira, alguém do time avisa: "terminei o relatório". Na quarta, o diretor pergunta pelo relatório e ele... não foi enviado. Estava terminado no sentido de "parei de trabalhar nele" — mas não estava revisado, não estava no formato que o diretor pediu e ninguém tinha sido avisado de que existia. Terminado, sim. Pronto, não.

A diferença entre os dois estados costuma ser um conjunto de etapas invisíveis que ninguém combinou de quem seriam:

• Testado ou conferido — alguém verificou que funciona, e não só em condições ideais? No caso do relatório: os números batem com a fonte?
• Revisado por outra pessoa — um segundo par de olhos passou pelo trabalho? Erros óbvios para os outros são invisíveis para o autor.
• Publicado / entregue no lugar certo — o código está em produção, o post está no ar, o documento está na pasta que o cliente acessa? Trabalho parado na máquina de alguém não existe para o resto do mundo.
• Comunicado — quem depende dessa entrega ficou sabendo que ela aconteceu? Uma feature no ar que ninguém anunciou é quase tão inútil quanto uma feature que não subiu.

Times sem DoD acumulam trabalho "90% pronto" — que, na prática, é a pior categoria que existe: consome esforço como trabalho feito e entrega valor como trabalho não feito. E o efeito colateral é estatístico: se cada pessoa conta "pronto" de um jeito, as métricas de entrega do time viram ficção. Velocity, burndown, taxa de conclusão — tudo passa a medir "coisas que alguém declarou prontas", não valor entregue.

Como construir a DoD com o time (e não para o time)

Uma Definition of Done imposta de cima vira papel de parede: fica bonita na wiki e ninguém segue. A que funciona é construída pelo time que vai cumpri-la — porque só quem faz o trabalho sabe onde ele costuma vazar. O formato mais simples é uma conversa de 45 a 60 minutos, que pode acontecer numa retro ou numa sessão dedicada:

1. Comecem pela dor. Pergunte: "quais entregas recentes voltaram, deram problema ou geraram retrabalho? O que faltou nelas?" Cada resposta é uma candidata a item da DoD. Se o time de conteúdo já publicou post com link quebrado, "todos os links testados" entra na lista.
2. Escrevam itens verificáveis. Cada linha da DoD precisa ter resposta sim/não. "Código com boa qualidade" não é verificável; "revisado por outra pessoa do time e aprovado" é. "Texto bem escrito" não; "revisado pelo editor e sem pendência de comentário" sim.
3. Cortem o que o time não controla. "Aprovado pelo cliente em até 2 dias" depende do cliente — não pode ser DoD. A lista só pode conter condições que o próprio time consegue cumprir.
4. Comecem curto. Cinco a oito itens. Uma DoD de vinte linhas ninguém consulta; uma de seis vira hábito. Dá para apertar depois (falo disso mais adiante).
5. Deixem visível. No quadro do time, no template do card, na descrição do board. DoD escondida em documento é DoD esquecida. No TeamBOX, times costumam colar a DoD na descrição da coluna final do board da sprint — o card só cruza para "Concluído PRD" quando a lista fecha.

E revisite: a DoD é um documento vivo. A cada retrospectiva, vale perguntar se algum item virou letra morta ou se algum problema recorrente merece entrar na lista.

DoD por tipo de trabalho: exemplos concretos

A estrutura é a mesma em qualquer área — muda o conteúdo da lista. Três exemplos de times fictícios, para calibrar o seu:

Time de desenvolvimento (a Aline, tech lead de um squad de produto)

• Código revisado e aprovado por pelo menos uma pessoa que não o autor
• Testes automatizados escritos e passando; suíte completa verde
• Testado manualmente no ambiente de homologação
• Publicado em produção (ou atrás de feature flag, se combinado)
• Documentação ou changelog atualizado quando o comportamento mudou
• Time e áreas impactadas avisados no canal de lançamentos

Time de conteúdo/marketing (o Rafael, coordenador de marketing)

• Texto revisado pelo editor (português, tom e dados conferidos)
• Fontes de todos os números citados linkadas ou arquivadas
• Imagens com direito de uso confirmado e crédito quando necessário
• SEO básico feito: título, meta description e links internos
• Publicado no canal certo, com link testado em desktop e celular
• Distribuição feita: newsletter/redes agendadas, stakeholders avisados

Time de operações/RH (a Camila, analista de RH que roda onboarding)

• Checklist do processo executado de ponta a ponta (acessos, equipamento, agenda da primeira semana)
• Conferido por uma segunda pessoa do RH antes do dia 1
• Gestor do novo colaborador confirmou recebimento da agenda
• Registros atualizados no sistema (dados, documentos, trilha de onboarding)
• Pesquisa de primeira semana agendada para envio automático

Repare no padrão: conferência, revisão por outra pessoa, entrega no destino final e comunicação aparecem nas três listas, só que traduzidos para a realidade de cada trabalho. É por isso que a DoD funciona tão bem fora da TI: o problema do "pronto elástico" não é de engenharia, é humano.

DoD × critérios de aceite: não confunda

Essa é a dúvida mais comum, e a distinção é simples:

• Definition of Done é geral. Uma lista só, que vale para todos os itens do time, sempre. Ela responde "esse trabalho atingiu nosso padrão de qualidade?".
• Critérios de aceite são específicos. Cada User Story tem os seus, descrevendo o comportamento que aquela entrega em particular precisa ter. Eles respondem "esse trabalho faz o que foi pedido?".

Um exemplo deixa claro. A história "como cliente, quero recuperar minha senha por e-mail" tem critérios de aceite próprios: o e-mail chega em até X minutos, o link expira, senha antiga deixa de valer. Já a DoD do time — revisado, testado, publicado, comunicado — é a mesma dessa história, da próxima e de todas as outras. Um item pronto de verdade passa nos dois filtros: cumpre seus critérios de aceite e a Definition of Done. Aceite sem DoD entrega a coisa certa mal feita; DoD sem aceite entrega com capricho a coisa errada.

Uma consequência prática: na sprint review, só demonstre itens que cumpriram a DoD. Mostrar trabalho "quase pronto" para stakeholders cria a expectativa de que ele está entregue — e a conta chega depois.

Quando afrouxar e quando apertar

A DoD não é dogma: ela deve refletir o custo real de errar naquele contexto. A régua é uma só — qual o estrago se isso sair sem tal verificação? — e ela autoriza mover a lista nas duas direções.

Aperte a DoD quando:

• Defeitos estão escapando para o cliente ou para outras áreas com frequência. Cada tipo de vazamento recorrente vira um item novo na lista.
• O custo do erro subiu: o time passou a mexer com dados sensíveis, pagamento, comunicação pública da empresa. O padrão de ontem não cobre o risco de hoje.
• O time amadureceu e o que era esforço extra virou rotina barata (ex.: automatizar testes deixou de ser caro — então "testes automatizados" pode entrar).

Afrouxe (com critério) quando:

• Itens da lista viraram teatro: todo mundo marca o checkbox sem fazer de verdade. Uma DoD que o time finge cumprir é pior que uma lista menor e honesta.
• Um item protege contra um risco que não existe naquele tipo de trabalho. Exigir "aprovação jurídica" para um post interno do time é burocracia, não qualidade.
• Estão fazendo um experimento descartável — um protótipo para testar uma hipótese em uma semana. Aí vale criar uma DoD explícita de experimento (mais leve, mas ainda escrita), em vez de simplesmente ignorar a oficial.

Duas regras protegem a integridade do acordo. Primeira: afrouxar é decisão do time, tomada antes, e registrada — nunca uma exceção silenciosa no dia da entrega, porque exceção silenciosa é o começo do fim de qualquer DoD. Segunda: a mudança vale dali para frente, nunca retroativamente para "salvar" um item da sprint atual. Se o item não cumpriu a DoD vigente, ele não está pronto — volta para o planejamento da próxima sprint, e o time discute na retro por que não coube.

Erros comuns com Definition of Done

Para fechar, os tropeços que mais vejo em times que estão adotando (ou ressuscitando) a DoD:

• DoD que ninguém escreveu. "A gente sabe o que é pronto" é a versão adulta de "confia". Se não está escrito e visível, cada pessoa carrega uma versão diferente na cabeça.
• Itens não verificáveis. "Com qualidade", "bem testado", "documentação adequada" — adjetivos não se auditam. Reescreva até cada linha ter resposta sim/não.
• Contar item pela metade nas métricas. "Fizemos 80% da história, conta 80% dos pontos" destrói a utilidade da velocity e do burndown. Pronto é binário; as métricas da sprint só funcionam assim.
• DoD como arma. Usar a lista para apontar culpados ("você não cumpriu o item 4!") em vez de proteger a qualidade. A DoD é do time, contra o retrabalho — não do gestor, contra as pessoas.
• Nunca revisitar. O time de seis meses atrás escreveu aquela lista para os problemas de seis meses atrás. Uma olhada por trimestre — ou quando uma entrega ruim escapar — mantém a DoD viva.
• Confundir DoD com processo de aprovação externo. Se a lista depende de terceiros que o time não controla, ela vira desculpa para item eternamente "quase pronto". DoD é sobre o que o time garante.

Se o seu time ainda não tem uma, o primeiro passo cabe na próxima reunião: peguem as três últimas entregas que deram dor de cabeça, perguntem "o que faltou para estarem prontas de verdade?" e escrevam as respostas em cinco ou seis linhas verificáveis. Pronto — no sentido estrito da palavra — vocês têm uma Definition of Done versão 1.