Definition of Ready no Scrum: o que é e como usar
A Sprint Planning começa, o Product Owner apresenta o primeiro item e ninguém sabe dizer como ele será testado. O segundo depende de uma API de outro time que ainda não existe. O terceiro é grande demais para caber em duas semanas. Duas horas depois, o time sai com uma Meta da Sprint vaga e itens que vão travar no meio do caminho. A Definition of Ready existe para evitar exatamente esse cenário: é um acordo do time sobre o que um item precisa ter para entrar na Sprint.
Em português, a Definition of Ready (DoR) aparece como Definição de Preparado ou de Pronto para Começar. Ela é a irmã menos conhecida da Definition of Done (Definição de Pronto) e, ao contrário desta, não faz parte do Guia do Scrum. Isso não a torna errada, mas muda a forma de usar: a DoR é uma prática complementar, que o time adota se ajudar e ajusta quando atrapalhar.
O risco de uma DoR mal desenhada é real. Ela pode virar um portão burocrático em que o time só aceita itens totalmente especificados, recriando dentro do Scrum a fase de requisitos que o ágil quis evitar.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é Definition of Ready
A Definition of Ready é uma lista curta de condições que um item do Product Backlog precisa cumprir antes de ser selecionado na Sprint Planning. Ela torna explícito um acordo que, sem ela, fica implícito e muda conforme o humor da semana: "o que o time precisa saber para conseguir puxar este item e terminá-lo dentro da Sprint?".
Ela serve para três coisas:
- Orientar o refinamento. O Product Owner e o time sabem o que ainda falta discutir em cada item.
- Proteger a Sprint Planning. O evento deixa de ser uma sessão de descoberta e passa a ser de planejamento.
- Reduzir itens bloqueados. Dependências e dúvidas aparecem antes de o trabalho começar.
A Definition of Ready está no Guia do Scrum?
Não. O Guia do Scrum 2020 não menciona uma Definition of Ready. O que ele diz, na seção sobre o Product Backlog, é que os itens que podem ser concluídos pelo Scrum Team em uma Sprint são considerados prontos para seleção na Sprint Planning, e que eles costumam ganhar esse grau de transparência por meio do refinamento.
Na prática, o Guia já traz um critério mínimo de "pronto para a Sprint": o item precisa ser compreensível e pequeno o bastante para caber numa Sprint. A DoR expande esse critério com o que o time considera necessário no seu contexto. Por isso, ela é coerente com o Scrum desde que não contradiga o Guia, por exemplo exigindo especificação completa antes de qualquer conversa.
Definition of Ready e Definition of Done: as diferenças
| Aspecto | Definition of Ready | Definition of Done |
|---|---|---|
| Pergunta que responde | O item está claro o bastante para começar? | O incremento está concluído com a qualidade exigida? |
| Momento de uso | Refinamento e Sprint Planning | Durante a Sprint e na hora de considerar um item concluído |
| Aplica-se a | Itens do Product Backlog | Incremento |
| Está no Guia do Scrum? | Não; é prática complementar | Sim; é o compromisso do Incremento |
| Obrigatória? | Não | Sim |
| Quem define | O Scrum Team | O Scrum Team, ou a organização, se houver padrão comum |
As duas se complementam: a DoR evita começar mal, e a Definition of Done evita terminar mal. Um time com DoR e sem DoD clara começa bem e entrega sem qualidade.
Exemplo de checklist de Definition of Ready
O modelo abaixo é um ponto de partida para um time de software. Copie, discuta com o time e corte o que não fizer sentido. Uma boa DoR cabe em cinco a oito itens.
Um item do Product Backlog está pronto para a Sprint quando:
- O valor está claro: sabemos para quem é e por que importa.
- Os critérios de aceite estão escritos e o time entende como testá-los.
- O time estimou o item e acredita que ele cabe numa Sprint.
- As dependências de outros times, fornecedores ou áreas estão identificadas e não bloqueiam o início.
- Protótipos ou referências visuais existem, quando o item envolve interface.
- O Product Owner está disponível para tirar dúvidas durante a Sprint.
- Não há pendência de aprovação externa (jurídico, segurança, compliance) que impeça a entrega.
Muitos times usam o acrônimo INVEST como referência para itens bem escritos: independente, negociável, valioso, estimável, pequeno e testável. Ele ajuda na conversa, mas não precisa virar regra literal.
Exemplos em outros tipos de projeto
- Implantação de um ERP numa indústria: o item "configurar o faturamento da filial do Paraná" só entra na Sprint quando as regras fiscais da filial estão confirmadas com a contabilidade e o ambiente de homologação está disponível.
- Campanha de lançamento de produto: a peça "landing page da pré-venda" só entra quando o preço e a data de lançamento estão aprovados e o texto jurídico da oferta foi liberado.
- Projeto em órgão público: o item "publicar o formulário de solicitação online" só entra quando a norma interna que define os campos obrigatórios foi publicada.
Esses exemplos são ilustrativos e mostram o padrão: a DoR trata o que, se faltar, impede o time de terminar o item dentro da Sprint.
Como criar a Definition of Ready do seu time
- Olhe para as últimas Sprints. Liste os itens que travaram ou voltaram para o backlog e pergunte: o que faltava saber antes de começar?
- Transforme as causas em condições. "Dependência do time de integração descoberta no meio da Sprint" vira "dependências identificadas e combinadas".
- Escreva a lista com o Scrum Team inteiro. Product Owner e Developers precisam concordar, porque a DoR regula a conversa entre eles.
- Mantenha curta. Cada condição a mais é uma barreira a mais. Se a lista passar de oito itens, provavelmente está tentando especificar demais.
- Use no refinamento, não só na Planning. O refinamento do backlog é o momento de levar os itens até a DoR; a Planning só confere.
- Revise na retrospectiva. Se itens prontos continuam travando, a DoR está incompleta; se o time recusa itens por detalhes, ela está rígida demais.
Quando a DoR atrapalha
- Vira portão de especificação. O time exige tudo definido antes de começar e para de conversar durante a Sprint. O Scrum conta com descoberta durante o trabalho.
- Vira desculpa. "Não está pronto, não pegamos" sem ajudar o Product Owner a deixar pronto transforma a DoR em escudo.
- Vira regra para tudo. Um ajuste pequeno, uma correção urgente ou um experimento rápido não precisam passar pela lista completa.
- Substitui a conversa. Nenhuma checklist substitui o Product Owner e os Developers conversando sobre o item.
Um sinal de equilíbrio: a maioria dos itens do topo do backlog cumpre a DoR antes da Planning, e o time ainda descobre detalhes durante a Sprint sem que isso bloqueie a entrega.
O próximo passo
Na próxima retrospectiva, peça ao time para listar os três últimos itens que travaram na Sprint e o que faltava saber antes de começar. Com essa lista, escrevam juntos a primeira versão da DoR e testem por duas Sprints antes de ajustar. Ela vai mudar a forma como vocês conduzem a Sprint Planning e como montam o Sprint Backlog. O guia completo de métodos ágeis e Scrum mostra como essas práticas se encaixam no conjunto.
Para dominar o backlog, os eventos e os compromissos do Scrum com método, o curso Agile Scrum Foundation da Projeto Diário cobre o framework completo e as práticas ágeis complementares em vídeo, com preparação para o exame ASF.
