Definition of ready
A Definition of Ready (DoR), ou definição de preparado, estabelece um entendimento comum da equipa sobre as condições necessárias para começar a trabalhar num product backlog item. Em outras palavras, indica quando um requisito está pronto para desenvolvimento.
Mas o que significa estar “ready”? Por que é importante definir uma definition of ready? E como criar critérios eficazes? Vamos explorar estas questões passo a passo.
Muitas equipas Scrum enfrentam falhas na conclusão dos sprints porque iniciam trabalho em requisitos que não estão suficientemente refinados. Por vezes, os requisitos não são testáveis ou dependem de fatores externos. Portanto, a melhor forma de evitar estes problemas é definir uma DoR clara, que toda a equipa compreenda e aceite.
CURSOS AGILE
O que é uma Definition of ready?
No Scrum, a Definition of Ready funciona como uma checklist. Ela garante que um item do backlog, como uma user story, está compreendido, definido e acordado entre developers e Product Owner. Dessa forma, reduz-se a probabilidade de mal-entendidos e falhas durante o sprint.
Durante o refinamento do backlog, a equipa revisa cada item até se sentir confortável para se comprometer com ele no Sprint Planning. Se o requisito não cumprir os critérios da DoR, continua em refinamento.
Por que usar uma Definition of Ready?
Evita desperdício de tempo.
Reduz ambiguidades.
Previne tarefas mal definidas.
Aumenta a confiança no Sprint Planning.
Facilita entregas de valor previsíveis.
Exemplo de critérios de Definition of Ready
Cada equipa adapta os critérios conforme as suas necessidades. Um exemplo prático:
Descrição completa e compreensível.
Critérios de aceitação claros, usando a técnica Given–When–Then.
Discussão com o Product Owner realizada.
Impacto no utilizador identificado.
Testes necessários conhecidos.
Estimativa feita em story points.
Quando usar a DoR?
Durante o refinamento do backlog e antes do Sprint Planning.
Se um item ainda não cumpre os critérios da DoR, deve continuar em refinamento até estar pronto.
DoR vs DoD
É importante diferenciar DoR e DoD:
| Definição | Momento do uso | Foco | Objetivo |
|---|---|---|---|
| DoR | Antes do Sprint | Início do trabalho | Estar pronto |
| DoD | Após entrega do trabalho | Fim do trabalho | Estar concluído |
INVEST e a Definition of Ready
Muitas equipas usam o acrónimo INVEST como guia para a DoR:
Independent (Independente): Pode ser desenvolvido sem depender de outros itens.
Negotiable (Negociável): Pode ser ajustado conforme surgem novas informações.
Valuable (Valioso): Entrega valor real ao utilizador ou cliente.
Estimable (Estimável): A equipa consegue estimar esforço e complexidade.
Small (Pequeno): Deve caber num sprint ou ser desagregado.
Testable (Testável): Critérios de aceitação claros permitem validação rápida.
Cada letra do INVEST ajuda a equipa a avaliar se um product backlog item está pronto para desenvolvimento, garantindo maior previsibilidade e eficiência.
INDEPENDENT (Independente)
Deve ser possível desenvolver e completar o product backlog item (PBI) sem, dessa forma, desenvolver outros PBIs. Isto porque, a independência é importante para obter feedback rapidamente. Dessa forma, se um product backlog item exigir o desenvolvimento de outro o seu desenvolvimento poderá estar bloqueado. Ainda mais, a equipa pode ter de esperar muitos sprints para obter feedback. Por fim, não nos podemos esquecer que o Scrum é uma abordagem empírica que procura inspecionar e ajustar frequentemente.
NEGOTIABLE (Negociável)
Nem a equipa nem nenhum stakeholder deve ver, desse modo, um product backlog item refinado como um contrato. Em vez disso, a equipa com os restantes stakeholders deve, dessa maneira, mudá-lo quando mais e melhor informação for conhecida. De maneira idêntica, é importante ter critérios de aceitação claros. Por outro lado, as especificações não podem ser tão detalhadas que digam como os developers devem fazer o trabalho. Em outras palavras, é a equipa que define o “como” o trabalho deve ser feito, como parte do trabalho de planeamento do sprint.
VALUABLE (Valioso)
O product backlog item deve, assim, entregar valor ao cliente. Em outras palavras, o PBI deverá entregar valor aos utilizadores. Ainda mais, os utilizadores devem compreender de forma clara que valor é esse. A melhor forma de garantir que o PBI tem valor é, desse modo, escrever de forma clara o problema que estamos a tentar resolver. Em vez de se focar, por exemplo, exclusivamente na descrição do que se está a desenvolver. Assim, é mais claro para todos o valor que a equipa está a entregar.
ESTIMABLE (Estimável)
O product backlog item deve, desse modo, estar suficientemente compreendido e definido. Dessa forma, a equipa consegue realizar uma estimativa do tamanho do trabalho envolvido, para isso pode, por exemplo, usar story points.
SMALL ENOUGH (Pequeno)
Um product backlog item deve ser, dessa forma, suficientemente pequeno para poder ser completado num único sprint. Idealmente, até deve ser suficientemente pequeno para que, dessa maneira, seja entregue vários itens num único sprint. Caso não seja possível realizar um requisito num sprint, a equipa deve, desse modo, desagregar o requisitoos em requisitos mais pequenos (e.g., user stories). Isto porque, product backlog items mais pequenos aumentam a probabilidade de sucesso!
TESTABLE (TESTÁVEL)
O product backlog item deve ter critérios de aceitação claros que descrevem, dessa maneira, como o item pode ser validado. O product owner juntamente com os stakeholders devem escrever os critérios de aceitação de forma clara para que a equipa consiga rapidamente ver que o product backlog item está completo. No entanto, não se esqueça de que não deve ser assim tão detalhado que se torne não-negociável.
Conclusão
A Definition of Ready é essencial para equipas ágeis que querem entregar valor consistentemente. Ela assegura que os requisitos estão suficientemente refinados antes do desenvolvimento, reduzindo riscos e melhorando a qualidade. Além disso, promove colaboração, comunicação e responsabilização dentro da equipa. Por fim, aumenta a produtividade e melhora o fluxo de trabalho.
Em suma, este artigo explica o conceito de Definition of Ready (DoR) no Scrum, detalhando critérios práticos para avaliar quando um item do backlog está pronto para desenvolvimento. Destina-se a equipas ágeis em Portugal que querem melhorar o planeamento de sprints, reduzir desperdícios e aumentar a eficiência. Aplicar a DoR ajuda a criar um ambiente de trabalho mais organizado, previsível e colaborativo.