BT

Usando a definição de pronto

Muitas equipes usam a Definição de Concluído ("Definition of Done") para definir que uma história de
usuário está concluída e o produto está pronto para ser entregue. Mas o que dizer das histórias de
usuários que uma equipe recebe do seu Product Owner? As equipes podem verificar a qualidade
das histórias de usuários usando a Definição de Pronto ("Definition of Ready").

Alan Bustamante escreveu um post no seu blog sobre a definição de pronto, uma prática essencial
para aumentar a produtividade da sua equipe ágil de planejamento. Ele explica como a Definição de
Pronto pode ser usada para verificar a qualidade das histórias de usuário antes de trazê-las para o
planejamento.

Enquanto o valor da Definição de Concluído e Acordo de Trabalho da Equipe têm sido bastante
utilizados por equipes ágeis, na minha experiência, a Definição de Pronto é uma das menos
utilizadas, existe ainda ferramentas mais poderosas que uma equipe ágil pode utilizar. Enquanto a
Definição de Pronto pode ser usada para vários artefatos e atividades (Product Backlog, Sprint
Review, entre outras), para novas equipes prefiro começar com uma Definição de Pronto para a
seleção de itens de backlog, que introduz o conceito de preparação no planejamento, uma parte
importante do trabalho contínuo.

Quais são os benefícios que uma Definição de Pronto devidamente estruturada pode trazer para as
equipes? Alan relacionou alguns:

Medir o estado de "pronto" de um backlog;

Certifique-se que somente o suficiente dos itens do product backlog tenham sido pensados;
Ajudar a identificar quando o Product Owner ou outro membro da equipe estiverem
sobrecarregados;
Manter na equipe a responsabilidade dos seus membros uns pelos outros.
Reduzir a pressão para as equipes se comprometerem com estimativas antes das histórias
estarem "prontas";
Reduzir a quantidade de requisitos colocados durante o desenvolvimento.
No artigo do blog Como melhorar o rendimento da Sprint com a definição de pronto", Shrikant
Vashishtha explica como a definição de pronto pode ser usada para resolver o problema de equipes
trabalhando em histórias incompletas. Shrikant afirma que:

Simplificando, qualquer história do usuário que vem para dentro da Sprint Backlog tem que estar
pronta e qualquer história de usuário saindo da Sprint deve estar concluída.

O Product Owner e a equipe trabalham juntos para definir primeiro a história do usuário e, em
seguida, fazer o planejamento:

Como uma história de usuário torna-se clara e a equipe não tem qualquer pergunta sem resposta
ou algum bloqueador para a mesma, a história é considerada pronta. A equipe então estima a
história do usuário usando o conceito de pontos ("Story Points"). Esse processo continua para
todas as outras histórias de usuário da sessão. Para algumas histórias, o Product Owner leva uma
nota de perguntas sem resposta e guarda essas histórias no backlog para uma análise posterior.

Shrikant mencionou os benefícios que a definição de pronto podem trazer:

Trabalhar no sentido de "histórias prontas" ajuda bastante o Product Owner a se organizar melhor.
Ao mesmo tempo, ajuda ainda mais a equipe para que seus membros não fiquem esperando
indefinidamente que bloqueios sejam resolvidos durante o Sprint.

Os métodos ágeis têm a intenção de que as pessoas de negócios e desenvolvedores trabalhem

juntos diariamente e usem a comunicação cara-a-cara, tanto quanto possível. A Definição de Pronto
deve apoiar isso e não deve impor muitas regras sobre o Product Owner e a equipe, como Stefan
Roock explica em Definição de Pronto: "Uma faca de dois gumes":

(...) A Definição de Pronto pode ser usada para criar um processo mais regulado que impede a
colaboração entre a equipe de desenvolvimento e o Product Owner. Sempre que há problemas de
comunicação entre o Product Owner e a equipe de desenvolvimento, a definição de pronto é
prorrogada por uma nova política. Depois de várias "melhorias" a Definição de Pronto requer que
o Product Owner especifique cada exigência correta, completa e consistente e é pré-marcada por
um outro Product Owner e um Arquiteto de Software para evitar qualquer ambiguidade ou detalhes
que faltam. Isso não é Scrum e não é Ágil.
A organização deve impedir que a Definição de Pronto se torne pesada e se transforme em um
obstáculo para a colaboração e a comunicação:

Para a Definição de Pronto eu recomendo: Quanto menor, melhor. A equipe se torna mais e
mais capaz de lidar com informações incompletas. Portanto, a Definição de Pronto deve estar
encolhendo ao longo do tempo e não crescendo (enquanto normalmente a Definição de Pronto
está crescendo com as capacidades da equipe).

Stefan Wunder oferece 5 dicas sobre como obter o seu Backlog Pronto:

Definir a sua própria Definição de Pronto, junto com a equipe e o Product Owner. A visão idealista
de uma história de usuário "pronto-pronto" é que a equipe pode implementá-la sem interrupções.

Apenas a equipe de desenvolvimento está autorizada a chamar uma história de usuário realmente
pronta. Portanto, a equipe de desenvolvimento verifica cada história de usuário, se ela preenche
os critérios de sua Definição de Pronto ou não.

Use rótulos, cores, semáforos, prefixos ou o que preferir usar para enfatizar as histórias de
usuários que estejam realmente prontas no seu backlog. Não importa como as sinalize, contanto
que isso seja fácil de visualizar, quando olhar para o seu backlog.

Use rótulos, cores, semáforos, prefixos ou o que preferir para enfatizar as estórias de usuário que
estejam realmente prontas no seu backlog.

Faça questões abertas (que impedem que as histórias de usuários de estarem "realmente prontas)
transparentes para todos (...) para que todos saibam o que impede uma história de usuário de
estar realmente pronta e, portanto, precisa ser resolvida primeiro.

Certifique-se de que o Product Owner e a equipe de desenvolvimento entenderam os benefícios

de um backlog realmente pronto. Forneça seu apoio sempre que for necessário até que a
Definição de Pronto fluir através das veias de todos. Viva sua Definição de Pronto!

BT