Definition of ready
A Definition of Ready (DoR), também conhecida por definição de preparado, estabelece o entendimento comum da equipa sobre as condições necessárias para começar a trabalhar num product backlog item. Ou seja, estabelece o que significa um requisito estar pronto (“ready”) para desenvolvimento.
Mas o que significa estar “Ready”? Porque é importante definir uma “definition of ready”? Como definir uma boa “definition of ready”? Neste post iremos tentar responder a estas questões.
Muitas equipas scrum falham o cumprimento dos sprints por terem começado a trabalhar em requisitos do product backlog que não estavam suficientemente refinados. Por vezes os requisitos não são testáveis. Outras vezes não é possível completar os requisitos por existirem dependências externas. A melhor forma de combater este problema é definir uma “Definition of Ready” clara, que a equipa compreenda bem e se sinta confortável.
O que é uma Definition of ready?
Em scrum, a Definition of Ready é uma checklist que assegura à equipa que um product backlog item, definido por exemplo no formato de user story, está totalmente compreendido, definido e acordado entre os developers e o product owner. Por outras palavras, a equipa compreende perfeitamente o requisito antes de começar a trabalhar nela. Dessa forma, reduz-se a probabilidade de existirem mal-entendidos. Para assegurar que um product backlog item está “ready”, a equipa de desenvolvimento refina-o até estar confortável para se comprometer com ele durante o sprint planning.
INVEST e a Definition of Ready
Muitas equipas usam o acrónimo INVEST como critério para a sua definição de ready. Esta sigla INVEST significa
- Independent (Independente)
- Negotiable (Negociável)
- Valuable (Valioso)
- Estimable (Estimável)
- Small (Pequeno)
- Testable (Testável)
Desta forma, cada letra representa uma característica que um product backlog item, definido por exemplo no formato de user story, deve ter de forma a ser considerado preparado para ser desenvolvido. Em seguida, vamos explorar cada uma destas características em detalhe.
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.
Em suma, a Definition of Ready é uma importante prática de desenvolvimento de produto. Ela permite garantir, dessa forma, que a equipa só trabalha em requisitos que estão suficientemente refinados. Como resultado, a Definition of Ready melhora a qualidade no trabalho e a permite entregar mais rapidamente. Ainda mais, também ajuda a promover colaboração, comunicação e responsabilização entre os membros da equipa, Por fim, permite melhorar o fluxo de trabalho e aumentar a produtividade das equipas.