Definition of Ready (DoR): as suas user stories estão prontas?

Espera aí! Prontas para quem?

Quantas vezes você já ouviu “isso é fácil”, “mas é só adicionar um botão”, “não precisa detalhar, o DEV já sabe o que fazer” e “começa aí e depois eu atualizo a user story”? Não precisamos mais de documentação, foi o que muita gente disse (esquivando-se de certas responsabilidades) quando o Manifesto Ágil foi lançado em 2001: Software em funcionamento mais que documentação abrangente.

O desenvolvimento ágil de fato simplificou bastante coisa para que os times pudessem responder às mudanças de negócios de maneira mais efetiva e eficiente. Contudo, entender os problemas e necessidades dos clientes sempre esteve em evidência: Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado é o primeiro princípio ágil. Se menos tempo for investido em criação de documentação, mais cedo o time começa a trabalhar no projeto e, consequentemente, entrega o produto adiantado. Parece lógico, não é mesmo?

Na prática, no dia a dia, nos deparamos com diversos desafios e obstáculos que afastam o cliente da equipe de desenvolvimento tornando o trabalho da PO mais árduo, pois detalhes e informações podem ser perdidos ou distorcidos por conta de ruídos de comunicação e aquela esperança de entregar o software mais rapidamente cai por terra por conta de inúmeros retrabalhos. A Definition of Ready (DoR) pode minimizar o impacto desses ruídos ao melhorar a escrita de user stories, tornar o entendimento de requisitos mais colaborativo e agilizar as entregas.

O que é Definition of Ready (DoR)?

De uma forma prática e objetiva, a DoR representa critérios ou condições que um requisito necessita cumprir para que possa ser implementado e testado pelo time. É um checklist com itens que, se satisfeitos, tornam o requisito claro e detalhado o suficiente para que o trabalho seja iniciado. Em Scrum teams, a DoR garante a qualidade no início da Sprint: uma user story ready significa que o item está pronto para ser adicionado no Sprint Backlog. Em Kanban teams, geralmente significa que o item de trabalho pode entrar na fila TO DO (podendo variar de acordo com as políticas explícitas de cada equipe).

Jeff Sutherland, co-criador do framework Scrum, descreve a DoR da seguinte forma: “Ter uma definição de pronto significa que as histórias devem ser imediatamente acionáveis. A equipe deve ser capaz de determinar o que precisa ser feito e a quantidade de trabalho necessária para concluir a história do usuário ou PBI.
A equipe deve entender os critérios de “pronto” e quais testes serão realizados para demonstrar que a história está completa. As histórias “prontas” devem ser claras, concisas e, o mais importante, acionáveis” (Scruminc, tradução livre).

A DoR é uma prática ágil disponível no mercado e não faz parte nem do framework Scrum nem do método Kanban. Geralmente, é apresentada como um checklist personalizado por cada equipe, podendo ter itens em comum com outros times ou até mesmo padronizados e definidos pela empresa. Ela pode ser aplicada em um ou mais itens de trabalho (story, bug, tech debt, etc.) assim como é possível ter uma DoR para cada um. Como a PO é responsável por criar as user stories e alimentar o Product Backlog ela acaba tendo que cumprir todos os critérios antes de apresentar as user stories para o time podendo delegar alguns itens para outras pessoas conforme acordado com a equipe.

Um possível desentendimento pode acontecer entre Definition of Ready (DoR) e Definition of Done (DoD) por conta da tradução de inglês para português. Um exemplo disso é a própria tradução de DoD no Scrum Guide que interpreta “done” como “pronto”. No meu entendimento, eu traduzo “ready” como “pronto”: uma user story ready está pronta para ser iniciada ou trabalhada. Já “done”, significa “feito” ou “concluído”: uma user story done foi desenvolvida e testada (atende aos requisitos de qualidade) e está pronta para ser implantada em produção. De uma certa forma, as duas definições envolvem algo “pronto” e por isso pode gerar confusão.

Por que utilizar a DoR?

Para ouvir as necessidades do time de desenvolvimento. Apesar da DoR estar centrada em requisitos e user stories, ela, na verdade, torna visível o tipo de informação e detalhes que o time precisa para executar o seu trabalho de forma ágil sem perder a qualidade de suas entregas.

Entretanto, nem sempre as dores e necessidades do time são perceptíveis. Por isso, as seguintes situações podem indicar que a DoR é imprescindível para eles:

Esses são apenas alguns dos sintomas que podem indicar a necessidade de implementar a DoR no time. Note que eles podem ser causados por disfunções na equipe ou até mesmo na empresa e nem sempre a DoR resolverá todos os problemas. Mesmo assim, a sua utilização pode melhorar a comunicação entre a PO e o time além de tornar mais assertivo o que está sendo desenvolvido e testado. A ideia é garantir que o time não perca tempo trabalhando em algo que não está pronto para ser iniciado.

Como utilizar a DoR na sua equipe?

A melhor forma é educar o time sobre o significado de DoR e definir os critérios de forma colaborativa, ouvindo a PO, os DEVs, QAs, UI/UX designers e demais papéis que atuem no desenvolvimento de software. Seja através de workshop ou apresentação o importante é garantir que todos tenham o mesmo entendimento sobre a DoR e que isso seja documentado de forma acessível (Confluence, Notion, Wiki, doc no Google drive).

Caso a empresa defina os critérios da DoR para os times basta apresentá-los e juntamente com a PO garantir que sejam cumpridos. Por outro lado, se as equipes possuem autonomia para definir a DoR, o checklist pode ser criado da maneira que quiserem. A pergunta é: como fazer isso? Seguem três dicas para gerar insights sobre critérios a serem utilizados como parte da DoR do seu time.

Como, Eu quero, Então

Uma das formas mais práticas de melhorar a escrita de user stories é adotar algum dos modelos disponíveis no mercado. Além de facilitar a leitura, o seguinte template deixa claro quem é o cliente, qual é o seu problema e a sua importância.

Como … (QUEM). Para quem estamos construindo isso? Quem é o usuário?
Eu quero … (O QUE). O que estamos construindo? Qual é a intenção?
Então … (PORQUÊ). Por que estamos construindo isso? Qual é o valor para o cliente?

Esse formato é apenas uma das diversas formas de escrever user stories. Mesmo se o time quiser adotar outro padrão, o importante é que ele seja claro e possa ser replicado em outros itens do backlog.

INVEST

O acrônimo INVEST define seis critérios que uma boa user story deve ter:

Uma forma de utilizar o INVEST é instigando o time a pensar sobre esses critérios durante o entendimento de requisitos, como, por exemplo, o Product Backlog Refinement. Utilize as seguintes perguntas para puxar a conversa: time, essa story possui alguma dependência? Existem outras formas de solucionar o problema? Qual o valor que será entregue para o cliente? Está claro o problema que precisamos resolver? É possível estimar o tamanho da user story? Não está muito grande? Conseguimos entregar na próxima Sprint? Está evidente o que precisa ser testado?

Critérios de aceitação

A sintaxe Gherkin, popularmente conhecida no BDD (Behavior Driven Development), auxilia na escrita de cenários e regras de negócio que, posteriormente, serão utilizados nos testes e automações. Os critérios de aceitação representam o T (Testável) do acrônimo INVEST.

Dado que … (CONTEXTO). Descreve o contexto inicial do sistema: a cena do cenário. Normalmente é algo que aconteceu no passado.
Quando … (AÇÃO). Descreve um evento ou uma ação. Pode ser uma pessoa interagindo com o sistema ou pode ser um evento acionado por outro sistema.
Então … (RESULTADOS). Descreve um resultado ou resultado esperado.

Entender como a story será validada pela PO ou cliente antes mesmo de implementá-la evita diversos desperdícios e torna claro o escopo do requisito.

Dica bônus!

As três dicas apresentadas são algumas das diversas práticas disponíveis no mercado que foram comprovadamente testadas e aprovadas por inúmeras equipes ao longo das últimas duas décadas. Contudo, a melhor dica que eu posso dar para você iniciar a conversa sobre DoR é a seguinte: pergunte ao time o que eles precisam. Simples assim. Time, como podemos melhorar a qualidade das user stories? Vocês precisam de alguma documentação adicional? Algum tipo de informação específica para os DEVs front-end e back-end? Quem sabe o link para os protótipos das telas? QAs, como deixar mais claro os cenários de negócio que precisam ser validados? Nada melhor do que perguntar aos especialistas, perguntar para quem de fato executará o trabalho. Após isso, experimente adotar um padrão de escrita e, posteriormente, incrementar com os critérios do INVEST e de aceitação.

Considerações finais

A Definition of Ready é uma prática simples de ser implementada em qualquer time e torna mais efetivo o entendimento de requisitos entre a PO e o time. É um trabalho que começa de forma assíncrona com a PO detalhando a user story conforme os critérios da DoR e termina de forma colaborativa com o time confirmando se aquele incremento está pronto ou não para ser trabalhado. A intenção não é burocratizar o processo. Então, seja flexível de acordo com cada contexto e deixe claro os riscos caso a equipe tenha que iniciar a implementação de algo que não esteja 100% pronto. Evoluir faz parte da aprendizagem e tenha em mente que a PO precisa de tempo para preparar as user stories e o time para entender o que “ready” significa para eles.

Defina uma Sprint para teste ou selecione algumas user stories para experimentar a DoR com o time. Começar aos poucos minimiza aquela sensação de frustração, pois eles estarão rodando um experimento e isso gerará aprendizados. Utilize a retrospectiva para analisar o que pode ser melhorado nas próximas iterações. Se o time estiver inseguro, comece com apenas três critérios ou aplique a DoR em um projeto ou produto mais simples e de menor risco. Revise periodicamente os itens de trabalho do Product Backlog com a PO. Chegar preparado para as sessões de refinamento poupará tempo de todos. Entenda que a DoR é um checklist vivo e ele será atualizado à medida que o time evolui. Talvez eles percebam que alguma informação não seja mais relevante ou que o seu formato mudou.

Eu prefiro trabalhar primeiramente com a DoR ao invés da DoD. Não é uma regra, mas eu tenho percebido maiores benefícios já que os times tendem trabalhar de forma mais segura e objetiva quando sabem de fato qual é o problema que precisa ser resolvido e quando eles possuem as principais informações para iniciar o trabalho. Contudo, ter uma user story ready não significa que não haverá mais interação entre os DEVs e a PO após o início do desenvolvimento. Lembre-se de um dos princípios do Manifesto Ágil: Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. A comunicação “cara a cara” (mesmo que virtualmente) segue sendo o método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento (6º princípio ágil). Não deixe os processos e as ferramentas sobreporem os indivíduos e as suas interações.

Referências