Como criar e manter uma definição de pronto (DoD) que o time respeita

1. Por que a DoD falha na prática (e como evitar as armadilhas comuns)

A DoD genérica que ninguém lê

Muitos times começam com uma Definition of Done copiada de um template da internet. Listas como "código revisado", "testes unitários passando" e "documentação atualizada" viram wallpaper digital. O problema não é o conteúdo, mas a ausência de apropriação. Quando a DoD não reflete as dores reais do time, ela se torna um checklist burocrático que ninguém consulta.

Exemplo de DoD genérica que falha:

- Código commitado no branch principal
- Testes unitários com cobertura > 80%
- Code review aprovado
- Documentação técnica atualizada
- Homologação com PO realizada

O viés do "feito" subjetivo

Sem critérios objetivos, desenvolvedores podem considerar uma história "pronta" porque o código compila, enquanto o PO espera uma funcionalidade completamente testada em staging. Essa divergência gera retrabalho e quebra a confiança.

Cenário comum:

Desenvolvedor: "O código está pronto, subi para produção."
PO: "Mas o tratamento de erro quando o servidor cai? E a mensagem de validação do formulário?"

DoD como instrumento de punição

Quando a liderança usa a DoD para cobrar entregas incompletas ou culpar times por atrasos, ela vira uma ferramenta de controle hierárquico. O time passa a "burlar" os critérios ou a criar DoDs tão frouxas que perdem o valor.

2. Construindo a DoD com o time (não para o time)

Workshop de cocriação

Reúna desenvolvedores, QA, PO e scrum master. Use a técnica "Start, Stop, Continue" para listar o que já funciona, o que atrapalha e o que falta. Cada pessoa escreve em post-its os critérios que considera essenciais para considerar um item "pronto".

Exemplo de dinâmica:

Rodada 1: "O que já fazemos e deve continuar na DoD?"
Rodada 2: "O que está faltando e nos causa retrabalho?"
Rodada 3: "O que deveria ser removido porque só atrasa?"

DoD mínima viável

Na primeira versão, inclua apenas 5 a 7 critérios essenciais. Deixe de fora itens que podem ser tratados como "boas práticas" ou que dependem de automação futura.

Exemplo de DoD v1.0:

- Código revisado por pelo menos um par
- Testes unitários passando (sem quebras)
- Testes de integração para fluxo principal
- Tratamento de erros implementado
- PO validou o comportamento em staging
- Nenhum débito técnico crítico identificado

Validação com PO e stakeholders

Após a cocriação, apresente a DoD ao PO e stakeholders. Explique que cada critério existe para evitar retrabalho e garantir previsibilidade. Negocie exceções apenas para cenários muito específicos.

3. Critérios essenciais que todo time técnico deve considerar

Qualidade técnica inegociável

  • Testes unitários e de integração passando
  • Code review com feedbacks endereçados
  • Ausência de warnings ou débitos críticos no linter
  • Documentação de API ou endpoints atualizada

Critérios de produto e UX

  • Aceite formal do PO na história
  • Tratamento de estados de erro (loading, vazio, falha)
  • Acessibilidade básica (navegação por teclado, contraste)
  • Mensagens de feedback para o usuário

Segurança e conformidade

  • Validação de dados sensíveis (não logar senhas ou tokens)
  • Rastreabilidade mínima (logs estruturados)
  • Permissões e roles verificadas

4. Como integrar a DoD ao fluxo do dia a dia (sem virar burocracia)

Checklists automatizados no board

Use templates no Jira, GitHub Projects ou Notion que já venham com a DoD preenchida. Cada item vira um checkbox que precisa ser marcado antes de mover para "Done".

Exemplo de template no GitHub Projects:

Definição de Pronto
- [ ] Código revisado
- [ ] Testes passando
- [ ] PO validou
- [ ] Sem débitos críticos
- [ ] Logs de erro implementados

Gatekeepers leves

Code review e QA não devem ser barreiras intransponíveis, mas pontos de verificação. Se um critério não for atendido, o item volta para "Em andamento" com justificativa clara.

DoD no refinement e planning

Antes de puxar uma nova história, o time revisa se a DoD atual ainda faz sentido para aquele tipo de item. Isso evita surpresas no meio da sprint.

5. Mantendo a DoD viva: revisão periódica e evolução natural

Retrospectivas focadas em DoD

A cada 2 ou 3 sprints, reserve 10 minutos na retrospectiva para perguntar:
- "Algum critério da DoD virou gargalo?"
- "Tem critério que não está sendo respeitado? Por quê?"
- "Precisamos adicionar algo novo?"

DoD por tipo de item

Nem todo item precisa da mesma DoD. Crie variações:

DoD para História:
- Todos os critérios da DoD padrão
- Testes de aceitação automatizados
- Documentação de usuário atualizada

DoD para Bug:
- Causa raiz identificada
- Teste de regressão criado
- Correção validada em staging

DoD para Spike:
- Relatório com descobertas
- Decisão técnica documentada
- Próximos passos definidos

Versionamento da DoD

Mantenha um histórico de mudanças em um arquivo no repositório do time. Isso ajuda novos integrantes a entender a evolução e evita discussões sobre "como era antes".

Exemplo de changelog da DoD:

v1.0 (2024-01-15) - Versão inicial com 6 critérios
v1.1 (2024-03-10) - Adicionado "tratamento de erros"
v1.2 (2024-06-22) - Removido "cobertura de 80%" (era gargalo)
v2.0 (2024-09-05) - Criadas variações por tipo de item

6. Lidando com exceções e pressão por velocidade

Exceções documentadas e rastreáveis

Quando um critério precisar ser pulado (ex.: prazo apertado), documente no próprio card:

Exceção aprovada em 15/10: pular testes de integração
Motivo: hotfix de segurança crítico
Plano de regularização: adicionar testes na sprint seguinte
Responsável: [nome do dev]

DoD mínima vs. DoD ideal

Sob pressão, negocie apenas o que é seguro abrir mão:
- Negociável: documentação extensa, testes de performance
- Não negociável: code review, testes de regressão, validação do PO

O papel da liderança técnica

O tech lead deve proteger a DoD explicando o custo de pular critérios, não apenas dizendo "não". Mostre dados de retrabalho e incidentes anteriores para justificar a rigidez.

7. Métricas para saber se a DoD está sendo respeitada (de verdade)

Taxa de retrabalho pós-entrega

Meça quantos itens voltam para correção após serem marcados como "pronto". Se esse número for alto, a DoD não está sendo seguida ou está incompleta.

Tempo médio entre "pronto" e "em produção"

Se o tempo for muito longo, pode haver gargalos escondidos (ex.: espera por validação do PO, falta de ambiente de staging).

Pesquisa de confiança no time

A cada mês, faça uma pesquisa anônima:

"Em uma escala de 1 a 5, o quanto você confia que os itens marcados como 'pronto' realmente atendem a DoD?"

Se a média ficar abaixo de 3,5, é sinal de que a DoD precisa ser revisada ou reforçada.

Referências