Várias pessoas já me perguntaram como escrever uma boa Definition of Ready, para diminuir a quantidade de impedimentos do time durante a Sprint. Acredito que a primeira e principal dica é ter user stories bem escritas e que sejam de fácil entendimento. Já li user stories que beiravam os dois limites do universo: as que pareciam telegramas, de tão econômicas e as que pareciam uma especificação técnica, de tão detalhadas.
Bem, o custo de elaboração de uma user story não é medido por palavra, então, o Product Owner não precisa usar a frase “uma user story é como um convite para uma conversa” ao pé da letra. Qualquer pessoa (do time e de fora dele, que tenha um mínimo de entendimento do projeto) deve entender o que será feito, até mesmo para conseguir entender qual é o valor da sua entrega.
Por outro lado, o Product Owner não precisa ter conhecimento técnico. Muito menos escrever uma especificação UML do que precisa. E eu já vi por aí user story com diagrama de caso de uso colado. E diagrama de classes! A responsabilidade da implementação técnica é do time. Se você tem um time que precisa da ajuda do Product Owner para implementar tecnicamente uma história… Meu amigo… Você tem um problema! E dos grandes!
O foco de hoje é sobre como escrever boas user stories. Um bom critério, tanto para o PO escrever, quanto para o time aceitar a história é usar o INVEST, um acrônimo criado por Bill Wake, formado por um lembrete das características de uma user story de qualidade. Este método é amplamente usado e é recomendado por Mike Cohn, um dos pais do Scrum.
O INVEST diz que uma boa user story possui seis características:
Independent: histórias são mais facilmente trabalhadas quando são independentes, ou seja, quando podemos implementá-las em qualquer ordem, já que não são intimamente ligadas, gerando uma cascata (que pode virar gargalo) de implementação. Talvez essa seja a característica mais difícil de alcançar totalmente.
Negociable: histórias não são contratos para implementar features; boas histórias captam a essências e não os detalhes de uma feature. Definida a essência, os detalhes são negociados com o Product Owner. E não definidos por ele.
Valuable: a premissa básica de uma história é que ela agregue valor ao produto, para o cliente. Muitas vezes as histórias começam a ser quebradas. Quando começamos a quebrar demais as histórias, temos que ter o cuidado de não transformá-la em algo que entregue apenas uma parte da feature.
Estimable: não precisa ser algo exato; o time não precisa acertar sempre; mas o time precisa ser capaz de estimar uma user story. Da mesma forma que uma história estimável pode ser negociada, ninguém consegue estimar uma história que não entende. Entendo que esta seja a característica chave de uma boa user story, por que está intimamente ligada a outras.
Small: boas histórias são pequenas. Elas entram no acordo entre Time e Product Owner sobre o tamanho máximo de uma história dentro da Sprint. Além disso, quando as histórias são menores, há chances maiores de ter uma estimativa mais precisa. É o típico caso de quando o Time joga para o alto a estimativa de uma história “por não entender o que implicaria sua implementação”. Se o time usar essa frase na planning, significa que a história deve ser revista.
Testable: é preciso testar! Sempre! Testabilidade sempre foi uma característica de bons requisitos; o mesmo é plenamente aplicável à user stories. Se o cliente não sabe como testar algo, significa que ou a user story não está clara o bastante ou que ela não contém algo que acrescente valor aos olhos do cliente.
Seguir estes pontos é importante para o Product Owner na escrita e para o Time na aceitação da user story. É preciso que todos estejam alinhados com o conceito de cada um destes critérios. Muitas empresas preocupam-se com a qualidade de seus produtos. Mas, antes de mais nada, é necessário ter a preocupação focada nas histórias que geraram o produto. Histórias de alta qualidade criam produtos de alta qualidade. Invista nas suas histórias e crie produtos espetaculares!
E quem aí não se lembra do velho conceito de GIGO?
Agile Momentum 