Neste artigo, quero explicar o que são DoR e DoD, qual é a diferença entre Definition of Ready e Definition of Done e como aplico esses conceitos em projetos reais.

Também vou relacioná-los a alguns conceitos mais amplos de qualidade que utilizo como referência no SAFe Framework .

O que são DoR e DoD?

As siglas DoR e DoD significam:

• DoR — Definition of Ready
• DoD — Definition of Done

As duas ajudam o time a criar critérios mais objetivos para o fluxo das tarefas.

De forma simples, eu gosto de pensar assim:

A Definition of Ready responde: “podemos começar?”

A Definition of Done responde: “podemos realmente considerar isso terminado?”

Essa diferença parece óbvia, mas ela resolve um dos problemas mais comuns que encontro em projetos: pessoas diferentes trabalhando com interpretações diferentes sobre quando uma atividade está pronta para começar e quando ela realmente terminou.

O que é Definition of Ready (DoR)?

A Definition of Ready é o conjunto de condições que eu espero que uma atividade cumpra antes de entrar em execução.

Em outras palavras, antes de começar uma tarefa, eu quero saber se o time possui informação suficiente para trabalhar.

Dependendo do projeto, eu verificaria pontos como:

• O objetivo da tarefa está claro?
• O problema que precisa ser resolvido está explicado?
• O resultado esperado está documentado?
• Os critérios de aceitação estão definidos?
• As principais dependências foram identificadas?
• Existem informações técnicas suficientes?
• Os fluxos principais e alternativos estão documentados?
• O time consegue estimar a atividade?
• As dúvidas críticas foram resolvidas?

Isso não significa tentar descobrir tudo antes de começar.

Projetos possuem incertezas, e muitas coisas só serão descobertas durante a execução.

Mas existe uma diferença enorme entre trabalhar com incerteza e começar uma tarefa que ninguém entendeu.

Se o time não consegue explicar o que precisa construir, talvez a tarefa ainda não esteja ready.

O que é Definition of Done (DoD)?

A Definition of Done estabelece as condições necessárias para que uma atividade ou entrega possa ser considerada realmente concluída.

Isso evita uma situação bastante comum:

O desenvolvimento terminou, mas o teste não.

O teste terminou, mas a documentação não.

A implementação terminou, mas ninguém fez a validação final.

A tarefa aparece como concluída no board, mas ainda existe trabalho pendente.

Nesse cenário, ela está realmente done?

Uma Definition of Done pode considerar, por exemplo:

• Critérios de aceitação atendidos;
• Validação funcional concluída;
• Testes executados com sucesso;
• Testes automatizados aprovados;
• Revisão técnica realizada;
• Documentação necessária atualizada;
• Padrões do projeto respeitados;
• Entrega formalmente aceita quando necessário.

O objetivo é criar uma compreensão compartilhada sobre o que significa dizer:

“Terminamos.”

Qual é a diferença entre DoR e DoD?

Para mim, a diferença pode ser resumida de forma muito simples.

A DoR protege a entrada da tarefa no processo.

A DoD protege a saída da tarefa do processo.

A Definition of Ready tenta evitar que uma atividade comece sem condições suficientes para ser executada.

A Definition of Done tenta evitar que uma atividade saia do processo antes de realmente cumprir aquilo que o projeto considera uma entrega concluída.

Se a DoR é fraca, eu espero encontrar:

• Mais dúvidas durante a execução;
• Mais interrupções;
• Mais tempo de espera;
• Estimativas menos confiáveis;
• Maior risco de retrabalho.

Se a DoD é fraca, eu espero encontrar:

• Tarefas marcadas como concluídas antes da hora;
• Problemas descobertos depois da entrega;
• Atividades sendo reabertas;
• Qualidade inconsistente;
• Retrabalho após o que deveria ser a finalização.

DoR, DoD e critérios de aceitação: não confunda os conceitos

Outro ponto importante é não tratar DoR, DoD e critérios de aceitação como se fossem exatamente a mesma coisa.

Eu gosto de separar assim:

• DoR: quais condições a tarefa precisa cumprir para começar?
• Critérios de aceitação: quais condições específicas aquela entrega precisa atender?
• DoD: quais condições precisam ser cumpridas para considerarmos o trabalho realmente terminado?

Os critérios de aceitação podem mudar de uma tarefa para outra.

Já DoR e DoD ajudam a criar um padrão compartilhado pelo time sobre a qualidade mínima esperada na entrada e na saída do processo.

Por que DoR e DoD são abandonadas?

Se esses conceitos parecem tão úteis, por que são abandonados com tanta frequência?

Tenho algumas hipóteses:

• Falta de experiência das lideranças do time;
• Dificuldade em convencer outras pessoas sobre a importância dessas definições;
• Falta de autoridade ou influência das lideranças;
• Projetos que já estão atrasados e começam a eliminar etapas do processo;
• Projetos de inovação, nos quais existe mais incerteza sobre tempo e resultado esperado;
• Produtos e projetos que nunca estabeleceram um processo suficientemente claro.

Existe um comportamento que vejo com frequência em projetos atrasados:

Como precisamos entregar mais rápido, começamos a remover controles de qualidade.

Reduzimos refinamentos.

Começamos atividades ainda pouco claras.

Diminuímos validações.

O objetivo é ganhar velocidade.

Mas, quando essas decisões aumentam dúvidas, erros e retrabalho, podemos acabar perdendo exatamente o tempo que tentávamos economizar.

Antes de mudar o processo, entenda quem precisa estar envolvido

Quando a dificuldade está relacionada à falta de influência ou autoridade, eu não tentaria simplesmente impor uma nova Definition of Ready ou Definition of Done.

Primeiro alinharia essas definições com os stakeholders que possuem maior influência e impacto sobre o projeto.

Esse é um ponto que aprofundo no artigo Como usar a matriz de stakeholders para aumentar sua influência e melhorar a comunicação do projeto .

DoR e DoD fazem parte de uma discussão maior sobre qualidade

Se você já possui influência e autonomia suficientes para trabalhar essas definições, eu gosto de ampliar um pouco a discussão.

DoR e DoD não são, para mim, conceitos isolados.

Eles estão ligados à qualidade do processo que transforma uma necessidade em uma entrega.

É por isso que gosto de relacioná-los a alguns conceitos de Built-In Quality do SAFe .

Esse também é o tipo de problema que o Saint Jude ajuda lideranças a observar com mais clareza: tarefas entrando no board sem informações suficientes, estimativas que não correspondem à realidade e riscos criados por definições pouco claras.

Shift learning left

O desenvolvimento de produtos inclui muitos cenários desconhecidos que o time descobre conforme o projeto avança.

O mesmo acontece com cada tarefa.

Quanto mais tarde descobrimos um problema importante, mais difícil e caro pode ser corrigi-lo.

Isso pode afetar escopo, qualidade, cronograma e custos.

Por isso, gosto de criar mecanismos que antecipem perguntas, cenários e validações sempre que possível.

Pair programming e peer review

Pair programming é uma prática conhecida, mas nem sempre utilizada de forma consistente.

Duas pessoas trabalham juntas na mesma atividade: uma concentra sua atenção na construção da solução, enquanto a outra ajuda a revisar decisões, identificar problemas e sugerir melhorias.

A ideia é trazer mais de uma perspectiva para a construção da entrega.

Mas existe uma realidade que também precisa ser considerada:

Se duas pessoas trabalham na mesma tarefa, elas não estão trabalhando em duas tarefas diferentes.

Qualidade possui custo.

E quase sempre existe pressão para aumentar velocidade.

Por isso, qualquer prática precisa ser analisada dentro do contexto do projeto, da capacidade disponível e do risco que estamos tentando reduzir.

Collective ownership e habilidades T-shaped

Outro conceito importante é reduzir a dependência excessiva de uma única pessoa.

Quanto mais conhecimento fica concentrado, maior é o risco para o projeto.

Ao mesmo tempo, não acredito que simplesmente dizer que todos devem conhecer tudo resolva o problema.

No início de um projeto, ou quando novos profissionais entram no time, o conhecimento sobre regras de negócio, arquitetura e histórico das decisões geralmente ainda é baixo.

Esse conhecimento precisa ser construído ao longo do tempo.

Padrões de artefatos e Definition of Done

Todo profissional possui padrões de trabalho.

Quando esses padrões são documentados e compartilhados, começam a se transformar em padrões do projeto.

E isso está diretamente relacionado à Definition of Done.

Se cada pessoa possui uma interpretação diferente do que significa uma entrega de qualidade, o status “Done” começa a perder significado.

Automação do workflow

Workflows frequentemente incluem passagens manuais de tarefas entre diferentes profissionais.

Cada passagem pode criar espera.

O time também pode perder tempo inspecionando tarefas manualmente ou procurando componentes que já existem e poderiam ser reutilizados.

Automatizar partes desse processo pode ajudar a reduzir tempo, custos e atividades manuais.

Na prática, isso está muito conectado ao que buscamos tornar visível no Saint Jude: onde as tarefas estão esperando, onde o fluxo está ineficiente e como trabalhos pouco claros podem afetar cronograma, custo e performance.

Como aplico Definition of Ready na prática

Agora chegamos à parte que mais me interessa: como transformar o conceito em processo.

Para criar clareza e melhorar a documentação das atividades, normalmente trabalho com um tripé formado por:

• PO — responsável pela expectativa de negócio;
• UI — responsável pelos fluxos e experiência esperada;
• Tech Leader — responsável pela orientação técnica.

Na construção da Definition of Ready:

• UI documenta o fluxo esperado e os fluxos alternativos;
• PO documenta o que é esperado como resultado de negócio;
• Tech Leader documenta as principais orientações técnicas para a construção.

Por quê?

Porque, na minha experiência, é muito difícil começar um projeto com todos os membros do time possuindo conhecimento e autoridade suficientes para tomar todas as decisões.

Por isso, inicialmente crio referências técnicas e de negócio capazes de orientar e validar as atividades.

Com o tempo, o objetivo é que o próprio time adquira conhecimento e autonomia suficientes para depender cada vez menos dessas referências.

Refinamento também faz parte da minha DoR

Existe uma regra prática que utilizo:

Se durante o refinamento o time ainda não entende o que precisa ser feito, a tarefa provavelmente não está pronta para entrar em execução.

Nesse caso, devolvemos a atividade para refinamento.

As perguntas levantadas pelo time se tornam novas informações que precisam ser documentadas.

O objetivo não é criar uma documentação perfeita.

O objetivo é reduzir dúvidas previsíveis antes que elas se transformem em bloqueios durante a execução.

Como aplico Definition of Done na prática

Na Definition of Done, volto a utilizar essas referências para validar e finalizar formalmente a entrega quando necessário.

Também utilizo testes como uma camada importante de segurança.

Dependendo do projeto, posso considerar como parte da DoD:

• Critérios de aceitação atendidos;
• Validação do PO;
• Validação de UI quando aplicável;
• Revisão técnica;
• Casos de teste executados;
• Testes unitários automatizados aprovados;
• Documentação atualizada;
• Padrões técnicos e de produto respeitados.

O principal objetivo é criar uma trava de segurança.

Se existem condições críticas que ainda não foram cumpridas, a entrega não deveria ser tratada como terminada.

DoR e DoD também ajudam a melhorar produtividade e previsibilidade

Quando uma tarefa começa sem clareza, o tempo não desaparece.

Ele reaparece durante a execução na forma de:

• Dúvidas;
• Mensagens;
• Reuniões;
• Espera;
• Retrabalho;
• Novas estimativas;
• Atrasos.

Da mesma forma, quando uma tarefa é considerada Done antes da hora, parte desse trabalho reaparece mais tarde como correção.

Por isso, eu não vejo DoR e DoD apenas como controles de qualidade.

Vejo também como mecanismos que ajudam a proteger o fluxo, a produtividade e a previsibilidade do projeto.

Como Saint Jude ajuda a identificar problemas de Ready e Done

É aqui que os dados do projeto começam a ficar especialmente interessantes.

Jira, Azure DevOps, ClickUp, Monday.com, Asana e outras ferramentas já possuem informações sobre tarefas, responsáveis, estimativas, movimentações, prazos e entregas.

O Saint Jude funciona como uma camada de inteligência sobre esses dados.

O objetivo é ajudar gerentes, PMOs e lideranças a identificar sinais como:

• Tarefas entrando em execução sem informações suficientes;
• Estimativas incompatíveis com a execução real;
• Atividades permanecendo tempo demais em determinados estados;
• Bloqueios recorrentes;
• Tarefas reabertas ou devolvidas para correção;
• Retrabalho recorrente;
• Atrasos que podem comprometer o cronograma;
• Impactos de problemas de qualidade sobre custo e produtividade.

Não se trata de transformar DoR e DoD em burocracia.

Trata-se de entender se as regras que o time definiu estão ajudando o trabalho a fluir melhor ou se existem problemas que continuam se repetindo.

DoR e DoD não deveriam existir apenas no papel

Chego ao fim deste artigo com uma ideia simples.

Criar uma Definition of Ready e uma Definition of Done não resolve nada se elas forem apenas listas esquecidas em uma página da documentação.

Elas precisam fazer parte da forma como o time trabalha.

A DoR precisa ajudar a impedir que tarefas sem condições mínimas entrem em execução.

A DoD precisa impedir que trabalho incompleto seja tratado como concluído.

E ambas precisam evoluir conforme o time aprende.

DoR define quando podemos começar. DoD define quando podemos realmente dizer que terminamos.

Se você quer entender onde tarefas mal definidas, retrabalho, bloqueios e problemas de qualidade estão afetando prazo, produtividade ou custo, conheça Saint Jude e seus módulos de inteligência de projetos .

E no seu time? Definition of Ready e Definition of Done fazem parte do processo ou só aparecem quando alguém lembra que elas existem?

Até breve!

Erik Scaranello