O que é a Definition of Ready?
A Definition of Ready (DoR) estabelece quais critérios um item do backlog deve atender antes de poder ser incluído em uma sprint. Simplificando: uma tarefa está "pronta" quando todas as informações necessárias estão disponíveis para que a sua equipe possa entendê-la e trabalhar nela.
No Product Backlog – a lista de todas as tarefas planejadas em um projeto – diversas tarefas se acumulam. Muitas delas são inicialmente formuladas de forma vaga ou não contêm detalhes suficientes para uma implementação concreta. A DoR atua como um filtro aqui e garante que apenas tarefas bem preparadas cheguem até a equipe.
Essa preparação acontece durante o Product Backlog Refinement (também chamado de Backlog Grooming). Nesse processo, as tarefas são discutidas em conjunto, refinadas e munidas de todos os detalhes necessários até atenderem aos critérios de "Ready".
Curiosamente, o Scrum Guide oficial não define uma Definition of Ready formal. Em vez disso, ele afirma que os Backlog Items são considerados "prontos para seleção" quando podem ser concluídos dentro de uma sprint. Mesmo assim, muitas equipes usam uma DoR como ferramenta prática no dia a dia.
Uma Definition of Ready típica pode ser assim:
Descrição clara: A tarefa é formulada de forma compreensível e todos na equipe sabem do que se trata.
Critérios de aceitação: Está claramente definido quando a tarefa foi implementada com sucesso
Estimativa: A equipe avaliou o esforço e sabe quanto tempo a implementação provavelmente exigirá
O que é a Definition of Done?
A Definition of Done (DoD) descreve com precisão o estado que um Increment deve atingir para atender aos padrões de qualidade exigidos. Um Increment é o resultado de trabalho concreto – como um recurso finalizado, uma função implementada ou uma User Story concluída.
Diferentemente da DoR, a DoD está oficialmente ancorada no Scrum Guide e é obrigatória para todos os membros da equipe. Ela cria transparência ao estabelecer um entendimento compartilhado dentro da equipe sobre o que "done" realmente significa.
A Definition of Done persegue três objetivos centrais:
Criar transparência: Todos na equipe e todos os stakeholders entendem o que significa "Done".
Garantir qualidade: Apenas o trabalho que atende a todos os padrões definidos é considerado completo
Clareza para releases: Apenas itens Done podem ser lançados ou apresentados na Sprint Review
O que acontece quando uma tarefa não atende à DoD? As consequências são claras: ela não pode ser lançada nem mostrada na Sprint Review. Em vez disso, retorna ao Product Backlog e aguarda lá por novo processamento.
Muitas organizações estabelecem uma DoD válida para toda a empresa, à qual todas as equipes devem, no mínimo, se ater. Se não existir uma definição padrão desse tipo, a equipe Scrum cria a sua própria. Quando várias equipes trabalham no mesmo produto, aplica-se a todas uma Definition of Done compartilhada.
Uma DoD prática pode conter estes pontos:
Código testado: Todos os testes unitários são executados com sucesso
Documentação atualizada: As alterações técnicas estão documentadas
Revisão de código realizada: Pelo menos um outro membro da equipe revisou e aprovou o código
Diferenças entre ready e done
Os dois conceitos se complementam perfeitamente, mas atuam em momentos completamente diferentes do processo de desenvolvimento. Aqui estão as principais diferenças em resumo:
Aspect
Definition of Ready
Definition of Done
Timing
Before starting work
After completing work
Purpose
Task is ready to start
Task meets all quality standards
Binding nature
Not formalized in Scrum Guide
Officially anchored in Scrum Guide
Responsibility
Product Owner and team together
Developers
Enquanto a DoR garante que as equipes não comecem com tarefas pouco claras ou incompletas, a DoD assegura que apenas trabalho de alta qualidade seja considerado completo. Juntas, elas formam uma estrutura de qualidade que possibilita processos fluidos no gerenciamento ágil de projetos.
Por que essas definições são importantes no gerenciamento ágil de projetos?
Imagine que a sua equipe comece a desenvolver um novo recurso, mas ninguém sabe exatamente o que deve ser construído. Ou ainda pior: após semanas de trabalho, a equipe ainda está discutindo se a tarefa realmente está finalizada. Esses são exatamente os problemas que a DoR e a DoD resolvem.
Os benefícios práticos aparecem no dia a dia:
Transparência da equipe: Todos sabem exatamente quando uma tarefa está pronta para começar e quando é considerada concluída
Melhor colaboração: Critérios claros evitam discussões intermináveis e mal-entendidos
Planejamento confiável: As equipes conseguem avaliar de forma mais realista o que é viável na próxima sprint
Maior qualidade: A DoD impede que soluções pela metade sejam apresentadas como "done"
Progresso mais rápido: Menos retrabalho e correções, porque os requisitos estão claros desde o início
No processo Scrum, a DoR e a DoD estruturam todo o fluxo de trabalho. Do planejamento na Sprint Planning, passando pela implementação diária, até a apresentação na Sprint Review – ambas as definições fornecem balizas claras. Embora sejam particularmente difundidas no Scrum, esses conceitos também funcionam em outros métodos ágeis como o Kanban ou até mesmo em abordagens mais tradicionais de gerenciamento de projetos.
Quem define a DoR e a DoD na equipe?
As responsabilidades por ambas as definições estão claramente distribuídas, e a colaboração entre todas as partes envolvidas é crucial para o sucesso.
Para a Definition of Ready, Product Owner e equipe de desenvolvimento trabalham lado a lado. O Product Owner garante que os Backlog Items sejam formulados de forma clara e compreensível. Os desenvolvedores verificam se entendem a tarefa e se conseguem estimar o esforço de forma realista. Juntos, eles desenvolvem os critérios da DoR durante o Product Backlog Refinement.
A Definition of Done está principalmente sob a responsabilidade dos desenvolvedores. O Scrum Guide enfatiza explicitamente o papel deles na garantia de qualidade por meio da adesão à DoD. Mesmo assim, toda a equipe Scrum – Product Owner, Scrum Master e desenvolvedores – desenvolve a definição em conjunto. Quando várias equipes trabalham no mesmo produto, todas devem usar a mesma DoD.
A chave para o sucesso: ambas as definições só funcionam quando todos os membros da equipe as entendem e apoiam. Não são regras impostas de cima para baixo, mas acordos desenvolvidos em conjunto.
Exemplos de critérios concretos
Conhecimento teórico é bom, mas exemplos concretos tornam a DoR e a DoD realmente tangíveis. Os exemplos a seguir mostram como essas definições podem ser na prática. Lembre-se: cada equipe adapta os critérios aos seus requisitos e métodos de trabalho específicos.
Exemplo de uma Definition of Ready
Uma User Story é considerada "Ready" em muitas equipes quando os seguintes pontos são atendidos:
Título e descrição presentes: A tarefa está formulada de forma clara (por exemplo, "Como usuário, quero poder redefinir minha senha.")
Critérios de aceitação definidos: está claramente descrito quando a tarefa foi implementada com sucesso
Dependências esclarecidas: todos os fatores bloqueadores foram identificados e resolvidos
Estimativa realizada: a equipe avaliou o esforço em story points ou horas
Design/mockups disponíveis: se necessário, designs visuais ou wireframes estão disponíveis
Viabilidade técnica verificada: não restam dúvidas técnicas ou incertezas em aberto
Com esses critérios, a sua equipe pode confiar que a tarefa pode ser trabalhada na sprint sem grandes surpresas.
Exemplo de uma Definition of Done
Uma tarefa atende à Definition of Done somente quando todos os seguintes pontos estiverem marcados:
Código escrito e commitado: todas as alterações estão salvas no sistema de controle de versão (por exemplo, Git)
Testes unitários criados: testes automatizados cobrem a nova funcionalidade e são executados com sucesso
Revisão de código concluída: pelo menos um outro membro da equipe revisou e aprovou o código
Testes de integração bem-sucedidos: a nova função funciona perfeitamente com o restante do sistema
Documentação atualizada: tanto a documentação técnica quanto os manuais do usuário estão atualizados
Critérios de aceitação atendidos: todos os requisitos definidos na User Story foram implementados
Sem bugs conhecidos: erros críticos foram corrigidos, problemas menores estão documentados
Somente quando todos os pontos estiverem realmente atendidos é que a tarefa será considerada concluída e poderá fazer parte do Increment.
Dicas para introduzir a DoR e a DoD na equipe
Introduzir a DoR e a DoD exige paciência e disposição de toda a equipe. Com as dicas a seguir, a implementação acontecerá de forma tranquila.
Estabelecimento gradual dos critérios
Não tente criar a definição perfeita logo no início. Em vez disso, comece com poucos, mas importantes critérios. Em um workshop conjunto, reúna os pontos que estão no coração de todos os membros da equipe.
Mantenha a primeira versão deliberadamente enxuta – três a cinco critérios são totalmente suficientes. A cada sprint, você acumula novas experiências e pode expandir ou ajustar as definições de acordo. Lembre-se: trabalhar de forma ágil significa melhoria contínua, e isso também se aplica à DoR e à DoD.
Garantindo a comunicação da equipe
Transparência é a chave para o sucesso. Discuta ambas as definições regularmente com toda a equipe, e não apenas em pequenos grupos. A Sprint Planning oferece a estrutura perfeita para verificar se todas as tarefas estão realmente "Ready".
Na Sprint Retrospective, vocês podem avaliar em conjunto quão bem a DoR e a DoD funcionaram. Documente ambas as definições em um local central que todos os membros da equipe possam acessar a qualquer momento – por exemplo, em uma ferramenta de gerenciamento de projetos como o MeisterTask. Assim você evita mal-entendidos e cria condições claras.
Revisão e ajuste regulares
Planeje momentos fixos para revisar as suas definições – aproximadamente a cada duas ou três sprints. Faça as seguintes perguntas:
Quais critérios se mostraram eficazes?
Onde houve problemas, apesar da DoR ou DoD?
Os requisitos do projeto mudaram?
Há novos insights do trabalho do dia a dia?
Obtenha feedback de todos os envolvidos, incluindo stakeholders fora da equipe de desenvolvimento. Definições rígidas contradizem a mentalidade ágil – mantenha-se flexível e adapte os critérios às condições alteradas.
Erros comuns e como evitá-los
Mesmo equipes experientes tropeçam em armadilhas típicas ao aplicar a DoR e a DoD. Se você as conhece, pode evitá-las desde o início.
Falta de clareza nos critérios
Critérios formulados de forma vaga são o erro mais comum. O que significa "suficientemente documentado"? Quanto é "testado o bastante"? Essas formulações confusas levam a interpretações diferentes e discussões intermináveis.
Em vez disso, formule critérios mensuráveis e verificáveis:
Em vez de: "Código está comentado"
Melhor: "Todos os métodos públicos possuem um comentário de documentação"
Discuta com a equipe exatamente o que cada critério significa e documente esses acordos. Quanto mais precisas forem as suas definições, mais fluida será a colaboração.
Documentação e testes subestimados
Muitas equipes focam apenas no desenvolvimento e se esquecem da documentação e dos testes. Isso volta para assombrá-las, no máximo, na próxima sprint, quando bugs aparecem ou novos membros da equipe não conseguem se orientar.
Testes e documentação fazem parte da DoD desde o início. Eles não são uma obrigação chata, mas um investimento no futuro do seu projeto. A dívida técnica resultante de testes ou documentação ausentes vai te alcançar mais cedo ou mais tarde – geralmente quando você menos pode arcar com isso.
Falta de comprometimento da equipe
A DoR e a DoD só funcionam quando toda a equipe está por trás delas. Se forem impostas por indivíduos ou pela gerência, faltará aceitação. O resultado: os critérios são ignorados, contornados ou implementados apenas pela metade.
Invista tempo em workshops conjuntos para criar as definições. Cada membro da equipe deve poder contribuir com a sua perspectiva. Esse desenvolvimento colaborativo cria entendimento e comprometimento – a base para uma aplicação bem-sucedida no dia a dia.
O seu próximo passo rumo à conclusão bem-sucedida do projeto
À primeira vista, a Definition of Ready e a Definition of Done podem parecer burocracia adicional. Na realidade, porém, são ferramentas poderosas que trazem clareza, estrutura e qualidade para a sua equipe.
A DoR garante que você só comece com tarefas bem preparadas. A DoD assegura que apenas o trabalho realmente finalizado seja considerado completo. Juntas, criam uma estrutura na qual as equipes podem trabalhar de forma eficaz e entregar resultados de alta qualidade.
Comece pequeno: desenvolva primeiro versões simples de ambas as definições com a sua equipe. Use os exemplos deste artigo como inspiração, mas adapte-os às suas necessidades específicas.
Com uma ferramenta como o MeisterTask, você pode integrar a DoR e a DoD diretamente ao seu fluxo de trabalho. Crie checklists para os seus critérios, documente as suas definições e acompanhe o status de todas as tarefas. Comece o seu teste gratuito hoje mesmo e veja como definições claras podem melhorar perceptivelmente o seu trabalho de projeto.
