Nesse artigo, traremos o conteúdo apresentado Product Owner, Felipe Soares no Enzimas #128. Exploraremos aqui, alguns pontos chave para a criação de boas histórias de usuário que auxiliem o time no desenvolvimento de uma boa solução.
Por que escrever essas histórias?
A verdade é que não basta repassarmos apenas o que deve ser construído para nossos desenvolvedores. Quando chegam novas demandas, precisamos também contextualizá-los do cenário, o contexto do nosso usuário. Mas por quê?
Se não fornecemos informações sobre o contexto, os desenvolvedores podem não compreender muito bem a solução. Com isso, podem ser desenvolvidas funcionalidades e features que não fazem sentido. E isso não só falando de negócio, mas também do usuário em si.
Desta forma, precisamos construir uma narrativa para que o time de desenvolvimento possibilite que faça sentido. Mas, mais do que isso, que também construa a solução de forma mais assertiva.
3 pontos base para uma boa história
Em primeiro lugar, devemos entender para quem pretendemos construir e entregar aquela funcionalidade. Ou seja, quem seria o nosso usuário.
Em seguida, devemos compreender o porquê, o motivo para querermos entregar essa funcionalidade para esse usuário. Com isso, devemos esclarecer qual é de fato a dor ou necessidade, que buscamos solucionar com o nosso produto.
Esses seriam os 3 pontos base. Já no conceito do “por quê?”, temos uma compreensão do como construir boas histórias de usuário.
Existem de fato, diversos templates de escrita de usuário disponíveis no mercado que podemos e devemos utilizar. No entanto, nenhum deles foge muito desses 3 pontos que direcionam o nosso entendimento acerca daquela necessidade.
Histórias de usuário: Desmistificando a escrita de User Story – dti (dtidigital.com.br)
Quando surgem as histórias de usuário?
As histórias podem surgir em diversos momentos. Podem vir tanto de: reuniões com cliente, teste com usuário, feedback, benchmark ou até de um discovery. Em resumo, elas podem vir de várias fontes diferentes.
Quando surgirem os insights, necessidades e identificações, é preciso escreve-las de forma que venham a fazer sentido no futuro, quando forem priorizadas. Nem sempre quando escrevemos uma história de usuário quer dizer que ela será construída imediatamente.
Ela entrará para o nosso backlog, e será construída quando fizer sentido, sendo próximo ou distante de quando foi cadastrada. Por isso devemos seguir os critérios abordados aqui, e escrevê-las de forma objetiva.
Em um primeiro momento, temos como prioridade documentar uma necessidade que foi encontrada. Por isso, deve ser curta e simples, já que a intenção ainda não é pensar em uma solução. Muito menos em como ela será feita.
Refinando as histórias de usuário
Ao ser priorizada no backlog pelo PO ou PM, a história de usuário passará então pelo rito de refinamento.
Quando falamos de refinamento, falamos da parte de negócios avaliando melhor a necessidade que atenderemos. Entendemos o que precisamos e quais são os critérios para atendê-la da melhor forma, com a melhor solução.
Por fim, selecionaremos quais são os critérios técnicos que envolvam a construção daquela história. Neste momento ela será refinada.
A técnica INVESPT
Uma técnica comum que pode nortear o momento do refinamento, é a chamada INVESPT. Este acrônimo exige que a história seja independente, não dependendo de outras para sua construção.
É necessário que ela seja negociável, para que a partir dela possamos gerar discussões. Para que que assim seja possível entender a partir desta a melhor solução.
Ela deve ser valiosa, é imprescindível que entregue valor ao nosso usuário. Ao mesmo tempo em que deve ser estimável, que o time consiga estimá-la.
Esta deve ainda ser pequena, ela deve caber em um ciclo de desenvolvimento, uma sprint que seja. E por fim, ela deve ser testável.
Este é o acrônimo INVESPT, que podemos utilizar no refinamento para que nos atentemos a estes pontos.
Boas práticas de refinamento
Não devemos nos limitar a utilizar técnicas como a INVESPT. Precisamos também buscar o envolvimento do cliente, tanto para que ele tenha um conhecimento do que queremos desenvolver, quanto para trazer insights. Tanto por parte do negócio quanto estratégica.
Precisamos ainda nos atentar à questão dos templates que foram abordados no artigo. Assim como a técnica INVESPT, é preciso entender que são boas práticas, mas não obrigatórias. Afinal, não existem fórmulas.
São boas práticas que são comumente seguidas, mas precisamos compreender o porque é interessante usá-las. São importantes para que tragamos para o nosso cenário, para o nosso time de desenvolvimento.
Isto porque, a forma que a escrita é desenvolvida varia muito entre POs e times de desenvolvimento. Isso acontece porque pode fazer mais sentido escrever de determinada forma para um time júnior. Enquanto para um time sênior ou pleno, talvez outra maneira seja mais bem aplicada.
Portanto, para o refinamento, precisamos de uma mobilidade de adaptação. Podemos utilizar de conceitos base, adaptando-os ao nosso cenário de forma que faça mais sentido.
O que devemos ter em mente é se nossas histórias de usuário respondem às perguntas: o quê, para quem e o porquê. É precisam que elas sejam simples e objetivas para que qualquer pessoa que venha a utilizá-la em algum momento, consiga entender.
Mas, mais do que entender precisamos que qualquer integrante do time, seja um dev, designer ou etc., consiga dar sequência à construção daquela funcionalidade, da feature.
Apenas assim, teremos histórias de usuário bem construídas.
