Definition of Ready: o checklist que toda Sprint deveria ter

Se você já participou de um Sprint que começou com entusiasmo e terminou em frustração, o roteiro provavelmente foi este: na segunda-feira do planejamento, o time puxou um item de backlog aparentemente simples. Na quarta-feira, ao começar o desenvolvimento, alguém descobriu que faltava a definição de uma regra fiscal crítica, que a API da empresa parceira ainda não estava homologada e que ninguém sabia exatamente o que deveria aparecer na tela de confirmação.

Resultado? O item ficou bloqueado por dias, a meta do Sprint foi pelos ares e o time terminou a quinzena estressado, empurrando trabalho inacabado para o ciclo seguinte. O diagnóstico desse problema comum raramente é incompetência técnica da equipe. Quase sempre, a causa-raiz é a ausência de uma Definition of Ready (DoR) — a Definição de Preparado.

Neste guia aprofundado, você vai entender o que é a DoR, qual a sua relação de equilíbrio com a Definition of Done (DoD), por que o Scrum Guide tem ressalvas sobre ela e como adotar um checklist prático e objetivo para proteger seu time contra desperdícios operacionais e retrabalho desnecessário.

O que é a Definition of Ready (DoR)?

A Definition of Ready (DoR) é um acordo de trabalho explícito e compartilhado entre o Product Owner e o Time de Desenvolvimento que estabelece as condições mínimas que um item do Product Backlog precisa cumprir antes de ser puxado para dentro de um Sprint.

Pense na esteira ágil como uma linha de montagem de alta precisão: se você alimenta a esteira com matéria-prima defeituosa ou pela metade, a linha trava ou o produto final sai com falhas graves. A DoR funciona como o controle de qualidade de entrada do Sprint. Ela não exige que tudo seja conhecido com certeza absoluta (o que violaria o empirismo), mas assegura que o item possui clareza suficiente para que o time inicie o trabalho sem bloqueios imediatos previsíveis.

DoR vs. DoD: os dois guardiões do Sprint

Uma confusão frequente entre profissionais iniciantes é misturar a Definition of Ready com a Definition of Done. Ambas são acordos de qualidade, mas atuam em momentos opostos da jornada de entrega:

Em resumo: a DoR garante que o trabalho entra redondo no Sprint; a DoD assegura que o trabalho sai pronto com excelência para as mãos do usuário.

Por que o Scrum Guide não formalizou a DoR?

Se a Definition of Ready é tão útil, por que ela não consta como uma regra obrigatória no Scrum Guide oficial de Ken Schwaber e Jeff Sutherland?

Os criadores do Scrum decidiram deliberadamente não tornar a DoR uma regra estrita por um receio legítimo: o risco de recriar a burocracia do modelo cascata (Waterfall) disfarçada de agilidade.

Quando mal interpretada, equipes imaturas usam a DoR como um "muro burocrático": os desenvolvedores cruzam os braços e dizem ao PO "não tocaremos nesta demanda até que você nos entregue um documento de requisitos de 30 páginas com 100% dos detalhes fechados". Isso destrói a colaboração e ressuscita a antiga fase de especificação engessada.

Porém, a maturidade de mercado demonstrou que, quando usada como um guia de colaboração e alinhamento mútuo, a DoR não afasta o time do PO — pelo contrário, ela cria um roteiro saudável para as conversas de refinamento contínuo do backlog.

Os 6 pilares de uma Definition of Ready de alta maturidade

Uma DoR eficiente não deve ser um formulário burocrático com vinte itens. Ela deve concentrar-se em seis dimensões essenciais:

1. Problema de negócio e beneficiário explícitos

O time sabe exatamente quem usará a funcionalidade e qual dor concreta ela resolve. Demandas que trazem apenas a solução técnica pré-concebida (ex: "criar botão vermelho na tela") sem explicar o propósito de negócio violam este pilar.

2. História estruturada segundo o modelo INVEST

O item foi formulado de forma a entregar uma fatia vertical independente e valiosa, sendo pequeno o suficiente para ser concluído com folga dentro do ciclo do Sprint. Saiba mais sobre como aplicar isso em nosso guia sobre como usar IA para escrever User Stories.

3. Critérios de aceitação objetivos e verificáveis

Nada de adjetivos vagos ("fácil", "rápido", "intuitivo"). O item deve conter critérios observáveis em sintaxe clara (como cenários Dado que... Quando... Então...), cobrindo o caminho de sucesso e os tratamentos de erro mais prováveis.

4. Dependências externas mapeadas ou resolvidas

Se o item depende de uma liberação do departamento jurídico, de uma autorização de segurança da informação ou da entrega de uma chave de API por um parceiro terceiro, essa dependência precisa ser endereçada antes do Sprint Planning. Puxar um item com dependência externa em aberto é uma das formas mais previsíveis de fracassar na Meta do Sprint.

5. Estimativa compreendida coletivamente

O time teve oportunidade de analisar o escopo durante as reuniões de refinamento, tirou dúvidas com o PO e expressou uma estimativa de esforço ou complexidade compatível com a capacidade histórica do time.

6. Insumos visuais e técnicos disponíveis

Para demandas que envolvem interface de usuário, os layouts, cópias de texto e fluxos essenciais de tela já foram validados e estão acessíveis para consulta dos desenvolvedores.

O Checklist prático de Definition of Ready (Pronto para copiar e colar)

Abaixo está um modelo testado e refinado em dezenas de operações ágeis corporativas. Você pode copiar este bloco e utilizá-lo como modelo de descrição padrão no seu Jira, Azure DevOps, ClickUp, Trello ou Notion:

Anti-padrões fatais: como a DoR pode dar errado

Para manter sua DoR viva e útil, fuja destes três comportamentos tóxicos comuns:

1. A DoR como desculpa para procrastinação (Arma contra o PO)

Quando a relação entre desenvolvedores e o Product Owner está desgastada, o time pode usar a DoR como uma barreira punitiva: "Falta a definição de uma vírgula na mensagem de erro, portanto recusamos o item e não faremos nada". A DoR deve ser um instrumento de colaboração. Se falta um detalhe pequeno que pode ser resolvido com uma conversa de 2 minutos durante a semana, o item pode entrar.

2. A DoR gigantesca e inatingível

Algumas organizações criam checklists com 25 exigências absurdas antes que qualquer linha de código possa ser escrita. Isso trava a inovação e transforma o refinamento em uma reunião interminável de burocracia. Mantenha seu checklist entre 5 e 8 pontos vitais.

3. O PO preenchendo a DoR sozinho no escuro

A DoR não é uma prova individual que o Product Owner faz em silêncio para apresentar aos desenvolvedores. Ela é o resultado das conversas de refinamento. Se o PO tenta preencher tudo sozinho sem ouvir a equipe técnica, premissas de arquitetura serão ignoradas e o time continuará travando durante o Sprint.

Como implementar a DoR com o seu time em 4 passos

Se o seu time sofre com itens inacabados e metas de Sprint descumpridas, proponha a adoção da DoR seguindo este roteiro simples:

1. Leve o tema para a próxima Retrospectiva: Mostre com dados reais quantos itens do último ciclo travaram por falta de insumos, regras não definidas ou bloqueios externos. Conecte a dor do time com a falta de um filtro de entrada.
2. Construam a primeira versão do checklist juntos: Em vez de impor um modelo pronto, projete o checklist acima e pergunte ao time e ao PO: "Quais destes itens teriam evitado o nosso último retrabalho?". Fechem um acordo inicial com 5 a 6 itens essenciais.
3. Rode um ciclo de teste de duas semanas: Aplique a nova DoR nas sessões de refinamento do próximo Sprint. Se um item importante não estiver pronto, conversem abertamente sobre o que falta para torná-lo 'Ready'.
4. Inspecione e adapte: Na retrospectiva seguinte, avaliem: o Sprint fluiu melhor? O time trabalhou com mais foco? Ajustem o checklist eliminando o que foi inútil e reforçando o que protegeu o ritmo de entrega.

Estudo de caso real: um item antes e depois da DoR

Para ver o impacto transformador da Definition of Ready na prática de um time, examine a comparação real entre uma demanda que causou caos e a mesma demanda após passar pelo filtro da DoR:

❌ ANTES DA DoR (O item que quebrou o Sprint):

Título: Melhorar o fluxo de recuperação de senha.
Descrição: "Os alunos estão reclamando que esquecem a senha e não conseguem acessar o curso. Precisamos arrumar isso com urgência para diminuir os chamados no suporte."
Critérios de aceite: "O sistema deve enviar um link de redefinição rápido e fácil."

O que aconteceu no Sprint? O desenvolvedor começou a programar na quarta-feira. Ele descobriu que a empresa de disparo de e-mails transacionais cobrava uma taxa extra por e-mails com token de segurança. Na quinta-feira, o designer reclamou que não havia layout para a tela de nova senha. Na sexta-feira, o PO perguntou por que a validação de caracteres especiais não havia sido implementada. O item foi empurrado para o Sprint seguinte, gerando atritos entre todos.

✅ DEPOIS DA DoR (O mesmo item pronto para o sucesso):

Título: Redefinição de senha com token de 6 dígitos via e-mail.
História de Usuário: Como aluno matriculado que esqueceu a senha, quero solicitar a redefinição pelo site e receber um código seguro por e-mail para cadastrar uma nova senha e retomar meus estudos sem depender do suporte manual.
Critério de Aceite 1 (Sucesso): Dado que o usuário informa um e-mail cadastrado na base, quando clica em 'Enviar Código', o sistema gera um token de 6 dígitos numéricos válido por 15 minutos e envia via Brevo, exibindo a tela de inserção do código.
Critério de Aceite 2 (Exceção de E-mail): Dado que o e-mail não existe no banco, quando o usuário clica em 'Enviar Código', o sistema exibe a mensagem amigável: 'Se este e-mail estiver cadastrado, as instruções foram enviadas' (evitando vazamento de base de dados).
Critério de Aceite 3 (Token Expirado): Dado que o token tem mais de 15 minutos, quando o usuário digita os 6 dígitos, o sistema rejeita a operação e exibe o botão 'Solicitar novo código'.
Não-Escopo: Recuperação via SMS ou WhatsApp deliberadamente fora deste ciclo.
Dependências Verificadas: Provedor Brevo configurado com template homologado; layout Figma anexado e validado pelo time.

O que aconteceu no Sprint? O desenvolvedor concluiu o item em dois dias e meio, o testador validou os 3 cenários sem dúvidas e o incremento foi entregue na Sprint Review 100% pronto e funcional. Esse é o poder de um critério de entrada bem definido.

Perguntas frequentes sobre a Definition of Ready

O que fazer se um item urgente não cumpre a DoR mas a diretoria exige sua entrada?

Se uma emergência real de negócio surgir, o Product Owner tem a autoridade de negociar com o time. O papel do Scrum Master é explicitar os riscos com transparência: "Podemos puxar este item sem a DoR concluída, mas o time terá 40% mais chance de não entregar o restante do Sprint devido a retrabalhos. Todos assumem esse risco?". Tornar o custo da decisão visível educa a liderança.

Quem tem a palavra final para dizer se um item está 'Ready'?

O Time de Desenvolvimento. O PO propõe os itens e traz as informações de negócio; os desenvolvedores avaliam se as informações são suficientes para que eles assumam o compromisso técnico com segurança durante o Sprint Planning.

A DoR substitui a Reunião de Refinamento (Backlog Refinement)?

Não. A DoR é o objetivo a ser alcançado dentro da reunião de refinamento. O refinamento é o ato de conversar, detalhar e fatiar os itens; a DoR é o padrão de qualidade que valida quando o refinamento daquele item chegou ao fim com sucesso.

Resumo

A Definition of Ready (DoR) é a ferramenta mais eficaz para eliminar o retrabalho e garantir que o Sprint comece com clareza, foco e fluidez. Combinando critérios de valor de negócio, ausência de dependências bloqueantes e critérios de aceite objetivos em Gherkin, ela protege o time de desenvolvimento contra o caos e ajuda o Product Owner a construir entregas com alto rigor de gestão.

Aprofunde seus conhecimentos sobre como o trabalho se organiza nos ciclos ágeis solicitando seu acesso gratuito ao curso e exame oficial SFC (Scrum Fundamentals Certified) da Ignição GP.