O que é Definition of Ready?
Em português: Definição de Preparado · Também conhecido como: DoR, Definição de Preparado
Definition of Ready é um acordo opcional sobre o que um item precisa esclarecer antes de entrar no trabalho, sem virar portão burocrático.
Definition of Ready (DoR), ou Definição de Preparado, é um acordo opcional sobre condições que ajudam um time a iniciar um item de trabalho com entendimento suficiente. Pode orientar o refinamento e a seleção de itens para a Sprint. Não é compromisso, evento ou artefato definido pelo Scrum Guide, nem deve impedir o aprendizado durante a execução.
Origem
A expressão Definition of Ready se difundiu entre equipes que usam práticas de desenvolvimento ágil, mas não há um criador único claramente estabelecido nas fontes consultadas. Ela surgiu como convenção para tornar visível o entendimento necessário antes de iniciar um item.
O Scrum Guide de 2020 não usa essa expressão. Ele descreve o refinamento do Product Backlog como atividade contínua e diz que itens prontos para seleção na Sprint Planning normalmente podem ser concluídos dentro de uma Sprint. Isso não equivale a prescrever um checklist universal. A DoR permanece prática complementar, adaptada ao contexto.
Fonte primária: The Scrum Guide
Na prática
Um item pode ter prioridade alta e ainda conter perguntas que impedem o trabalho. A DoR ajuda a reconhecer essas perguntas antes de assumir uma entrega. O time pode combinar, por exemplo, que entende a necessidade, conhece restrições decisivas, identificou dependências relevantes, sabe como vai medir se o item gerou o resultado esperado e consegue discutir um recorte pequeno o bastante para uma Sprint. A lista não precisa repetir documentos ou exigir todos os detalhes de solução antecipadamente.
O que acontece quando falta
Sem qualquer conversa sobre preparação, itens podem começar com decisões essenciais ausentes. As pessoas descobrem tarde uma dependência, esperam esclarecimentos e perdem opções de dividir ou reordenar o trabalho. A Sprint fica menos transparente.
Isso não significa que todo time precisa de uma DoR formal. Refinamento frequente, conversa direta e um Sprint Backlog claro podem dar conta do problema. A lista faz sentido quando melhora a percepção de risco antes de começar, sem impedir a adaptação posterior.
Como a Definition of Ready funciona
Um item pode ter prioridade alta e ainda conter perguntas que impedem o trabalho. A DoR ajuda a reconhecer essas perguntas antes de assumir uma entrega. O time pode combinar, por exemplo, que entende a necessidade, conhece restrições decisivas, identificou dependências relevantes e consegue discutir um recorte pequeno o bastante para uma Sprint. A lista não precisa repetir documentos ou exigir todos os detalhes de solução antecipadamente.
No refinamento do Backlog, as pessoas conversam sobre itens futuros, dividem trabalho quando necessário e registram decisões. A DoR pode servir como lembrete de temas que costumam ser esquecidos. Seu uso não torna o refinamento um evento obrigatório adicional do Scrum. Quando um item parece preparado, o time ainda poderá aprender algo novo durante a Sprint e adaptar o plano.
Preparado não quer dizer completamente especificado. Em trabalho complexo, parte da informação só aparece quando se experimenta uma solução, fala com usuários ou integra componentes. Se a DoR exigir certeza total, nada relevante passará. Pergunte qual incerteza precisa ser resolvida agora para começar com responsabilidade e qual pode ser explorada ao longo do trabalho. Uma hipótese de produto pode estar suficientemente preparada para um experimento mesmo sem uma regra final de interface.
Acordo do time, não autorização unilateral. Product Owner e Desenvolvedores precisam compartilhar entendimento sobre objetivo e possíveis caminhos. O PO ordena o Product Backlog; os Desenvolvedores planejam o trabalho da Sprint. Uma DoR redigida por uma função e usada para bloquear a outra tende a criar disputa. Construir a lista a partir de problemas reais torna seu propósito mais claro.
O tamanho importa. O Scrum Guide indica que itens selecionáveis para a Sprint normalmente podem ser concluídos dentro dela. Uma demanda grande pode precisar de divisão antes da Planning. Dividir não é cortar etapas de qualidade: cada parte deve ter um resultado que possa integrar um Incremento conforme a Definition of Done.
Os critérios de aceitação podem esclarecer comportamento de um item, mas não precisam seguir um formato único. A DoR pode lembrar de discutir exemplos quando ajudam; não precisa exigir uma longa especificação para todo cartão. A comparação completa entre DoR, DoD e critérios pertence ao verbete de Definition of Done.
Uma dependência conhecida merece registro e plano, porém sua existência não torna automaticamente o item proibido. Se a equipe pode resolver a dependência cedo, negociar com outra área ou começar por uma parte independente, a decisão pode ser razoável. O importante é não esconder um risco que inviabiliza o objetivo assumido.
Revise a DoR quando a realidade mostrar falhas ou excessos. Se várias Sprints sofrem com ausência de acesso a dados, incluir a verificação desse acesso pode economizar tempo. Se um item da lista nunca muda decisões, remova-o. A qualidade da DoR está na conversa que ela facilita, não no número de caixas marcadas.
Exemplo de Definition of Ready em um serviço digital
Imagine um time hipotético que pretende melhorar o agendamento de consultas. Um item inicial diz “permitir reagendar”. Antes da Sprint, 4 pessoas acreditam em comportamentos diferentes: uma imagina qualquer horário, outra só vagas livres, outra exige aviso à clínica e a última supõe que reagendar será permitido até a hora da consulta.
O time combina uma DoR curta: necessidade e público claros; principais regras de negócio discutidas; dependências que possam impedir o início identificadas; recorte viável dentro da Sprint. Ao aplicar o acordo, percebe que falta decidir quando o reagendamento fecha e como consultar vagas. Conversa com a área responsável, descobre uma regra para esse serviço e divide a entrega: primeiro, mostrar vagas elegíveis; depois, efetivar a troca e notificar a clínica. Os detalhes hipotéticos não representam política de uma empresa real.
Antes, o item inteiro poderia entrar na Sprint com perguntas decisivas ocultas e parar durante a construção. Depois, o time seleciona um recorte compreendido, mantém a dependência de integração visível e deixa outras perguntas para experimentos posteriores. A DoR não garantiu que nada inesperado surgirá. Ela evitou assumir, sem conversa, uma regra que ninguém havia definido.
Se uma oportunidade urgente aparecer no meio da Sprint, o time não precisa aguardar uma cerimônia de aprovação da DoR. Ele pode conversar sobre o que sabe, o que precisa descobrir e o efeito na Meta da Sprint. O acordo apoia julgamento, não substitui a decisão das pessoas envolvidas.
Como criar uma DoR enxuta
Observe impedimentos recorrentes
Liste situações em que itens começaram e pararam por falta de informação, acesso ou decisão. Procure padrões antes de escrever uma regra genérica.
Escolha poucas condições verificáveis
Formule perguntas que ajudam o time a decidir se consegue iniciar. Prefira “dependência externa identificada e plano combinado” a expressões vagas como “item completo”.
Converse com Product Owner e Desenvolvedores
Inclua quem conhece a necessidade e quem fará o trabalho. Use o acordo para revelar dúvidas, sem deslocar a responsabilidade de preparar ou planejar para uma única função.
Experimente no refinamento
Aplique a lista a alguns itens futuros. Registre o que ainda é incerto e o que precisa ser decidido antes de assumir um recorte na Sprint.
Selecione com julgamento
Na Sprint Planning, considere objetivo, capacidade e informação disponível. Uma condição não atendida pede conversa sobre risco e alternativas, não rejeição automática.
Revise após aprender
Na Retrospectiva, veja se uma condição evitou bloqueios ou apenas criou fila. Acrescente, simplifique ou retire itens conforme evidências do trabalho.
Erros comuns com Definition of Ready
- Tratar a DoR como regra oficial do Scrum. O Scrum Guide não a prescreve; sua utilidade deve ser julgada pelo contexto.
- Exigir especificação completa. A tentativa de antecipar toda descoberta paralisa trabalho complexo e torna o refinamento uma fase longa.
- Usar a lista como veto unilateral. Um acordo construído e interpretado pelo time favorece decisão; um portão imposto cria disputa.
- Copiar checklist de outro produto. Restrições importantes mudam entre serviços. Comece pelos impedimentos reais do seu fluxo.
- Confundir DoR com DoD. Preparação para iniciar não substitui o padrão de qualidade necessário para considerar um Incremento pronto.
- Nunca atualizar a lista. Condições que não evitam problemas viram cerimônia vazia; problemas recorrentes ignorados continuam atrasando trabalho.
Visão K21
O que a gente aprendeu na prática sobre Definition of Ready
Avelino Ferreira Gomes Filho, em Definição de Preparado, Pronto e Critérios de Aceitação, apresenta a DoR como acordo usado por muitos times e a relaciona a transições no fluxo. O próprio artigo reconhece que ela não aparece no Scrum Guide. A gente preserva essa distinção: uma prática útil pode complementar o framework sem virar regra oficial.
Renan Melo, em Armadilhas do Scrum, sugere revisar a DoR a partir da pergunta sobre o que deveria estar claro antes de começar. Também alerta para não ser radical com a lista. Esse é um bom critério de evolução: acrescentar uma condição quando ela previne uma dificuldade recorrente e retirá-la quando vira formalidade sem ajudar o trabalho.
Baseado nos posts: Qual a diferença entre Definição de Preparado, Pronto e Critérios de Aceitação?; Armadilhas do Scrum que impedem seu time de ser mais produtivo
Para se aprofundar
No blog da K21
- Qual a diferença entre Definição de Preparado, Pronto e Critérios de Aceitação?
Apresenta a DoR e sua relação com acordos de transição no fluxo.
- Armadilhas do Scrum que impedem seu time de ser mais produtivo
Sugere evoluir a DoR a partir de obstáculos observados na Sprint.
Fontes primárias
- The Scrum Guide, Ken Schwaber e Jeff Sutherland (2020)
Termos relacionados
Comparativos relacionados
Aprenda mais sobre os assuntos relacionados.
Scrum x Kanban
Framework para desenvolver produtos em ciclos curtos versus método de gestão de fluxo contínuo. Saiba quando usar cada um, e por que muitos times usam os dois.
Scrum Master x Product Owner
Dois papéis complementares dentro do mesmo time Scrum. Veja o que cada um faz e por que não devem ser exercidos pela mesma pessoa.
Scrum Master x Agile Coach
Mais do que dois cargos, uma progressão de carreira: o Agile Coach é um Scrum Master cujo raio de atuação cresceu para múltiplos times e a organização.
Perguntas frequentes
A Definition of Ready faz parte do Scrum Guide?
Não. O Scrum Guide de 2020 não define DoR como evento, artefato ou compromisso. Ele descreve refinamento contínuo e a seleção de itens que normalmente podem ser concluídos dentro da Sprint. Um time pode usar uma DoR como prática complementar, desde que não a confunda com uma exigência formal do framework.
A DoR deve bloquear um item na Sprint Planning?
Ela deve provocar uma conversa sobre a informação ou dependência que falta. Se o risco impedir uma entrega viável, talvez seja melhor refinar ou escolher outro recorte. Se o time consegue resolver a questão durante a Sprint sem comprometer a Meta, pode seguir com decisão consciente. A lista não precisa funcionar como veto automático.
Quem define a Definition of Ready?
O Time Scrum pode construí-la em conjunto, com Product Owner e Desenvolvedores discutindo que informação ajuda a começar trabalho. O Scrum Guide não atribui a uma função a responsabilidade de criar uma DoR, porque não prescreve essa prática. Revisões baseadas nos impedimentos reais do time tendem a ser mais úteis do que copiar um modelo externo.
Qual é a diferença entre DoR e DoD?
A DoR é um acordo opcional sobre preparação antes de iniciar um item. A Definition of Done é o compromisso formal do Incremento no Scrum e descreve o estado de qualidade necessário para considerar trabalho pronto. Uma não substitui a outra. Critérios de aceitação, por sua vez, esclarecem comportamentos de um item específico.
Todo item precisa de critérios de aceitação escritos para estar preparado?
Não existe exigência universal desse tipo no Scrum Guide. Alguns itens exigem exemplos escritos para reduzir ambiguidade; outros ficam claros com uma conversa breve e um resultado observável. Se o time decidir incluir critérios na DoR, vale esclarecer quando a condição ajuda e como evitar texto produzido apenas para marcar uma caixa.
