Histórias de usuário: Desmistificando a escrita de User Story

Artigo publicado em parceria com dti digital

O que implica a escrita de histórias de usuário? Quais os pontos devem ser observados? Qual deve ser nosso foco? Se você também tem esses questionamentos e busca essas respostas, vem comigo que vamos desmistificar esse assunto!

História ou Estória de usuário?

É comum encontrarmos os termos ‘estória de usuário’ e ‘história de usuário’ , quando estamos falando da escrita de features, e sabemos ambas derivam da expressão em inglês ; mas qual será a expressão correta?

Para entendermos melhor qual termo usar , vamos compreender inicialmente o conceito da expressão em inglês , que conceitualmente se refere a um requisito que é documentado no formato de uma história fictícia. Sabemos disso pois, na língua inglesa , temos a diferença entre os conceitos de história real (que realmente aconteceu) e história fictícia (fruto da nossa imaginação), sendo representados pelas palavras, e respectivamente.

No português , durante algum tempo também existia essa diferença que era representada pelas palavras (real) e (ficção), porém a palavra estória caiu em desuso na nossa gramática e passamos a utilizar somente a palavra história, representando os dois contextos (realidade ou ficção).

Resumindo, podemos dizer que para tradução e uso da terminologia em português, seguindo as regras gramaticais atuais de nossa língua o correto é que usemos a expressão ‘história de usuário’ .

Por que escrever histórias de usuário?

Uma pergunta muito comum que às vezes escutamos quando falamos em é: P or que devemos escrevê-las? Podemos dizer que , para o desenvolvimento de um produto , precisamos orientar nosso time sobre qual a nossa necessidade enquanto negócio, ou seja, deve ser construído. Mas dizer somente o que precisamos construir, muitas vezes não se mostra suficiente para o desenvolvimento da melhor solução, pois pode gerar muitas formas de interpretação pelo time impactando na entrega final ao usuário.

Precisamos então fornecer mais informações para contextualizar nossos desenvolvedores, para isso é preciso dizer a eles eles irão desenvolver alguma funcionalidade: Q uem é o meu usuário? Como ele é? Quais as suas dores e necessidades? Além disso, é preciso trazer também o meu usuário deseja aquilo: o que ele espera alcançar com aquela solução? Qual sua expectativa e resultado esperado?

De uma forma geral, podemos dizer que a escrita das histórias de usuário funcionam como uma narrativa sobre o quê, para quem e porque entregar aquela funcionalidade. É um direcionador ao desenvolvimento!

Existe um padrão de escrita?

Quando falamos em escrita de histórias de usuário , nos deparamos com alguns modelos mais utilizados (templates) pelos profissionais de produto, que nos conduzem a uma melhor representação da necessidade do negócio em uma escrita mais direcionada das features. Aliados a esses modelos, existem também algumas técnicas utilizadas , como o — who (quem)/ what (o quê)/ why (por que) — ; e a técnica do — card (cartão)/ conversation (conversa)/ confirmation (confirmação).

Na próxima seção , apresento um template de escrita e explico um pouco melhor sobre essas técnicas!

Um template para escrita de User Story

Um template muito utilizado é o do ‘Como/ eu quero/ para’, representado na imagem abaixo:

Veja que para escrever uma história de usuário é bem simples, basta que sigamos o modelo apresentado, trazendo as informações:

• Como — autor da ação (persona);
• eu quero — funcionalidade desejada;
• para — valor agregado à funcionalidade desejada.

Técnica 3W

Na utilização dessa técnica devemos nos atentar a o nosso sujeito ou usuário, ou seja, como o usuário se encontra (persona), o que ele deseja realizar e para quê ou porquê ele deseja executar aquela atividade ou ação. Seguindo o modelo apresentado acima temos:

• Como (quem?) — aqui eu devo referenciar para quem eu estou construindo aquela funcionalidade. Quem é a minha persona atingida por aquela história?
• eu quero (o quê?) — aqui eu devo colocar qual a funcionalidade esperada. O que minha persona deseja realizar?
• para (por quê?) — devo descrever qual a motivação para a construção daquela história. Qual o valor esperado pela pessoa usuária?

Técnica 3C

Esta técnica nos trás para uma preocupação com o conteúdo dos questionamentos da técnica do 3W. Os 3C representam card (cartão)/ conversation (conversa)/ confirmation (confirmação), onde:

• Cartão — uma User Story não deve ser muito extensa, tornando possível escrevê-la em um único cartão;
• Conversa — seu conteúdo deve gerar discussões de alinhamento entre o time sobre o que se deseja atender;
• Confirmação — é importante que a história de usuário possua critérios de aceitação para que seja possível a validação de êxito na construção e entrega.

Refinando uma História de Usuário

Toda que entra em fila de priorização do backlog deve passar por um processo de refinamento, onde ela é melhor detalhada pelo Product Owner e o time, para que além de eliminar incertezas, eles possa m ter mais entendimento do que deve ser feito para atender à quela necessidade, até mesmo avaliar se ela ainda faz ou não sentido para o contexto atual do produto.

Ainda nesse contexto , existem alguns pontos que devem ser definidos e algumas técnicas que podem ser utilizadas para auxiliar nesse processo de refinamento. Vamos a eles!

Técnica INVEST

Preocupado com a escrita de histórias de usuário, William C. Wake, em seu livro Extreme Programming Explore, criou o acrônimo , o qual traz as seis principais características a serem consideradas na criação, definição e escrita de uma história de usuário, que são:

• Independent (independente) — é uma história que não tem dependências ou amarrações com outras;
• Negotiable (negociável) — não existe um contrato fechado para as definições da história, ela está passível de conversas e ajustes se necessário, de acordo com uma mudança de contexto ou novas avaliações do time;
• Valuable (valiosa) — sua entrega representa entrega de valor para o usuário final;
• Estimable (estimável) — possui informações suficientes que garantem que o time a compreenda e que seja possível ser estimada;
• Sized-Appropriately/ Small (Tamanho Ideal — Pequena) — é uma história pequena que gera o mínimo de incertezas e que seja possível fazer parte de uma iteração;
• Testable (testável) — seja possível a definição de testes individuais da funcionalidade entregue pela história.

Critérios de Aceitação (Acceptance Criteria)

Na escrita das histórias também devemos possuir os critérios de aceitação, do inglês, acceptance criteria , que são como check lists que devem ser repassados para garantir que aquela história esteja entregando o que foi pedido e planejado em sua definição, em caráter de funcionalidade para entrega de valor ao usuário. Eles funcionam como uma forma de detalhamento maior sobre o que deve ser entregue naquela história, auxiliando também os desenvolvedores na definição e planejamento dos testes.

Não existe uma forma correta de escrita desses critérios de aceitação, eles podem ser em forma de tópicos ou mesmo através da descrição de possíveis cenários de uso do usuário.

Definição dos cenários em histórias de usuário

Uma forma de escrita dos critérios de aceitação pode ser através da definição de cenários que podem auxiliar o desenvolvimento de uma história de usuário pois traz os caminhos que um usuário pode percorrer em seu produto, finalizando no sucesso ou insucesso da tarefa, auxiliando assim nas tratativas desses caminhos previstos e alternativos.

Uma forma de escrita desses cenários pode ser utilizando do template conhecido como BDD. A técnica de desenvolvimento BDD — Behavior Driven Development , se caracteriza como sendo o desenvolvimento baseado no comportamento, onde os desenvolvedores descrevem o comportamento esperado para a funcionalidade a ser implementada, e valida a construção da estória em cima desse comportamento.

Na imagem abaixo eu trago um exemplo dessa técnica aplicada, onde é listad a a escrita do contexto da história e é representada a escrita do cenário correspondente.

Definição das Tarefas (Tasks)

Para as histórias de usuários , também devem ser definid a s as tarefas ( ) que fazem parte daquela história, ou seja, quais as tarefas são necessárias para a construção d a quela feature. Este ponto do refinamento da história é mais a nível de desenvolvimento, trazendo em uma linguagem mais direta do que precisa ser feito em caráter, na maioria das vezes, técnicos. Normalmente são definidas pelo próprio time de desenvolvimento.

Criação das interfaces com o usuário

Por último, dependendo da história a ser construída , pode ser necessário a representação de interfaces do sistema com o usuário. Estas representações podem vir em baixa fidelidade ( rabiscoframes, papel ) , em média fidelidade ( wireframes ) ou alta fidelidade ( protótipos navegáveis ou não ), desenvolvidas pela sua equipe de design UX/UI.

Algumas dicas importantes sobre escrita de histórias de usuário

Baseado no que conversamos até aqui neste artigo, sobre a escrita e refinamento de uma história de usuário, irei trazer algumas dicas que considero importantes, que vale a pena nos atentarmos ao definir nossas :

• Defina suas personas — não utilize a palavra usuário generalizando sua história, você precisa direcionar a sua escrita para o seu público alvo. Você não está construindo para todos!
• Nem sempre você vai usar o modelo clássico/padrão — tudo vai variar dependendo da maturidade e do que faz sentido para o seu time de desenvolvimento. O importante é que as perguntas sejam respondidas: quem, o quê e por quê.
• Não se estenda muito na escrita — histórias de usuário são lembretes para uma conversa no futuro. É importante não adicionar muitos detalhes na escrita inicial. Se atente a fornecer apenas o que é preciso para que seja possível sua discussão no momento correto.
• Tenha a participação do seu cliente — o cliente deve contribuir com a escrita da história de usuário junto com o time, com a finalidade de garantir que ambos tenham entendido o conceito e o que se espera com aquela história.
• Utilize o acrônimo INVEST — isso garantirá que sua história esteja o mais completa possível, possibilitando maior entendimento do seu time, eliminando, assim, possíveis falhas ou retrabalho.
• Liste os critérios de aceitação — sempre tenha definido quais são as condições, restrições e as regras de negócio do produto que precisam ser atendidas com aquela história.
• Descreva os cenários — Utilize a técnica BDD (Behavior Driven Development) para descrever os cenários daquela história. É importante que os cenários de testes sejam mapeados, em âmbito de negócio e comportamento.

Assimilando os conceitos

A descrição das histórias de usuário devem ser escritas de forma objetiva, ágil e simples, não cabe a ela s detalhes técnicos, ou definições de como serão feitas, o objetivo é especificar de forma simples as funcionalidades que o sistema vai ter.

Lembre-se de que , quando fizer sentido a construção da história (ela for priorizada pelo Product Owner), ela passará por um processo de refinamento junto ao time onde serão acrescentados todos os demais pontos importantes para seu desenvolvimento: critérios de aceitação, cenários de teste, detalhamento técnico.

Existe uma metáfora que acho muito interessante , que é a metáfora da cebola, a qual descreve muito bem esse contexto:

Imagine uma cebola : E la possui várias camadas até chegar ao seu núcleo. Imagine o produto sendo representado por esta cebola, e cada camada representa uma user story. O correto é que novas ideias sejam vistas como as camadas superficiais, onde não se entra em detalhes; porém , à medida em que vamos nos aproximando do núcleo , essas , sim , estão histórias de usuários devem estar mais detalhadas e completas (refinadas), com todos os pontos que discutimos neste artigo (descrição, critérios de aceite, cenários de teste), pois estas próximas do seu desenvolvimento e entrega para o usuário.

É importante dizer que não existe forma correta ou melhor para se escrever e refinar uma , existe o que é funcional para o seu time! Esse modelo que trouxe neste artigo é umà forma de escrita. O que vale é que quando for realizar a escrita de uma história de usuário, se preocupe em responder a essas três perguntas: Para quem? o quê? e por quê?, pois é isso que vai garantir o entendimento da sua história e sua construção de forma mais assertiva. Avalie o que faz sentido para o seu time de desenvolvimento!

Inicialmente, preocupe-se em entender o contexto do usuário e do negócio e trazer isso de forma clara para o seu time ou qualquer outra pessoa que acesse essa história de usuário, em nível de negócio e não em termos técnicos ou dizendo como fazer.

Originally published at https://www.dtidigital.com.br on August 25, 2021.