DoR (Definition of Ready) define quando uma história pode entrar na sprint; DoD (Definition of Done) define quando ela está realmente concluída. Sem essas duas listas, o time estima objetos diferentes: um desenvolvedor imagina o código, outro imagina o deploy, outro imagina o teste de aceite.
DoR: a porta de entrada do backlog
A Definição de Pronto para Fazer reúne as condições mínimas para um item ser estimado e planejado: descrição clara, critérios de aceite, dependências conhecidas e uma pessoa capaz de responder dúvidas. Itens que não passam pelo DoR voltam para o refinamento.
O DoR não precisa ser burocrático. Três ou quatro critérios objetivos já filtram a maioria dos itens vagos e evitam que a planning comece com uma história que ninguém entendeu. O importante é o time concordar com a lista e aplicá-la com consistência.
DoD: o que "pronto" significa de verdade
A Definição de Pronto lista tudo o que precisa existir para uma história ser considerada concluída: código revisado, testes passando, documentação atualizada, deploy realizado e critérios de aceite verificados. Cada time define a própria lista, alinhada ao seu contexto.
Sem DoD, cada pessoa tem um padrão particular de entrega. A consequência aparece no fim da sprint: histórias "prontas" para uns ainda precisam de dias de trabalho na visão de outros — e a velocidade registrada não corresponde à entrega real.
O impacto direto na estimativa
Quando o DoD é compartilhado, o voto de cada pessoa parte da mesma definição de conclusão, e a divergência passa a apontar diferenças reais de percepção de trabalho. Quando não é, votos próximos podem esconder entendimentos completamente diferentes de escopo.
O DoR também protege a estimativa: histórias preparadas convergem mais rápido e precisam de menos rodadas. Em termos práticos, bons DoR e DoD reduzem o tempo de planning e aumentam a confiança no número final.
Como criar sem burocracia
Comece com uma lista curta e revisável. Em uma retrospectiva, proponha o esqueleto do DoD e pergunte: "o que costuma faltar para considerarmos uma história concluída?". As respostas viram itens da lista. O DoR pode nascer de uma pergunta similar sobre o que falta antes de estimar.
Revisite as listas periodicamente. DoD e DoR não são documentos sagrados: eles evoluem com o time, o produto e a maturidade técnica. O teste final é simples — se as duas listas ajudam a planejar melhor, estão funcionando.
Checklist rápido
- DoR: descrição, critérios de aceite e dependências conhecidas.
- DoD: código, testes, deploy e verificação de critérios.
- As duas listas são curtas, explícitas e combinadas pelo time.
- Itens fora do DoR voltam ao refinamento.
- Listas revisadas em retrospectivas.
Leia também
- Refinamento ágil: como deixar histórias prontas para estimarAprenda a preparar backlog, critérios de aceite e perguntas de refinamento para chegar ao Planning Poker com histórias mais claras.
- Histórias de usuário e critérios de aceite: o guia INVEST para estimar melhorAprenda a escrever histórias de usuário com o modelo INVEST e critérios de aceite objetivos para melhorar o refinamento e o Planning Poker.
- Como facilitar uma planning de sprint objetivaBoas práticas para conduzir planning de sprint com timebox, alinhamento de capacidade, decisão de escopo e estimativas colaborativas.
Quer colocar em prática?
Crie uma sala grátis de planning poker free, chame o time e faça a primeira rodada em menos de 2 minutos, sem cadastro nem instalação.