Quando atuamos em projetos ágeis muitas vezes podemos acabar percebendo alguns desalinhamentos dentro do time de desenvolvimento ou até mesmo entre time de desenvolvimento e Produc Owner. Esses conflitos geralmente podem acontecer por dois fatores, sendo eles:

• O time pode estar recebendo requisitos com baixa granularidade ou com nenhum detalhamento. Além disso pode ocorrer de histórias maiores que a capacidade do time de entrega entrem para a sprint.

• Cada integrante do time entrega a sua feature ou a atividade que está responsável de uma forma diferente, ou seja, um integrante pode entender que apenas desenvolver já é o suficiente enquanto outro pode entender que o entregável é um software desenvolvido e com testes unitários.

Diante desses dois possíveis conflitos que podem acontecer durante o desenvolvimento de um produto podemos resolver com o DOR e DOD, também conhecidos como Definition of Ready e Definition of Done .Ambos servem como um acordo entre o time que deve ser visível e comum a todos os membros do time. Inclusive, se um novo integrante entrar para a equipe, ele deve ser informado a respeito dos critérios de DOR e DOD.

DOR - Definition of Ready: é um acordo que ocorre entre o time de desenvolvimento e o Product Owner onde ambos acordam o que é necessário para que uma estória entrar na sprint de modo que a equipe de desenvolvimento consiga desenvolve-la sem grandes problemas e que ela caiba na capacidade do time no período da sprint.

Exemplos de Definition of Ready:

• A estória deverá ter critérios de aceite detalhados
• A estória deve estar escrita seguindo o princípio INVEST
• Deve ter um wireframe de baixa fidelidade disponível e validado pelo cliente final

DOD - Definition of Done: também é um acordo feito com o time e Product Owner onde as expectativas alinhadas referem-se ao incremento do produto que será entregue ao final da sprint. Neste momento o Product Owner sugere o como ele espera que o entregável seja apresentado a ele ao fim do sprint.

Exemplos de Definition of Done:

• Os testes unitários devem ser feitos atingindo uma cobertura de 70% no mínimo
• A aplicação deve ser disponibilizada em ambiente de homologação
• Realizar Code Review

De modo geral, tanto o DOR quanto o DOD são acordos feitos para melhorar o fluxo de trabalho dando transparência sobre o que é necessário para iniciar uma estória e o que é necessário para finalizar um estória dentro de uma sprint.