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

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

Estória ou Histó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 user story; mas qual será a expressão correta?

Para entendermos melhor qual termo usar, vamos compreender inicialmente o conceito da expressão em inglês user story, 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, history e story respectivamente.

No português, durante algum tempo também existia essa diferença que era representada pelas palavras história (real) e estória (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 user story 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 user story é: Por 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, o que 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 para quem eles irão desenvolver alguma funcionalidade: Quem é o meu usuário? Como ele é? Quais as suas dores e necessidades? Além disso, é preciso trazer também o por quê 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!

Na nossa gamificação falamos sobre isto e muito mais! Bora lá?

Existe um padrão de escrita na história de usuário?

Quando falamos em escrita de histórias de usuário, nos deparamos com alguns modelos mais utilizados (templates) pelos profissionais de produto. Isso 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 3W – who (quem)/ what (o quê)/ why (por que) –; e a técnica do 3C – 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!

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 quem é 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.

Um exemplo de uma user story, seguindo o template apresentado e as técnicas descritas acima ficaria assim:

Refinando uma história de usuário

Toda user story 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. Isso ocorre para, além de eliminar incertezas, o time possam 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.

Nesse sentido, é importante entender que as vezes pode ser necessário a quebra das User Story em itens menores para entrega de valor em menor período de tempo ao usuário. Para atender aquela proposta de valor apresentada inicialmente, pode demorar muito tempo até o usuário conseguir enxergar de fato o seu valor.  Assim a quebra atua de forma a gerar valor ao entregar partes menores da feature principal, mas que façam sentido ao usuário.

Ainda nesse contexto, existem alguns pontos que devem ser definidos e 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 INVEST. Nele temos 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.

Exemplo

Vamos voltar ao exemplo anterior para entendermos melhor a aplicação dos conceitos apresentados:

User Story

         COMO vendedor

         EU QUERO visualizar os produtos da loja

         PARA ver sua quantidade em estoque

Para realizar a quebra dessa user story, eu posso pensar no que eu preciso para atender a essa necessidade do meu usuário, e o que precisarei construir para de fato chegar ao resultado esperado.Então imaginemos que o sistema dessa minha loja ainda não é informatizado, então antes de pensar na visualização dos produtos e sua quantidade em estoque eu tenho primeiro que cadastrar os produtos, dar entrada no valor em estoque, dar baixa nos produtos vendidos, etc.

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

Na escrita das histórias, também devemos possuir os critérios de aceitação. Eles são como checklists 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. Os critérios de aceitação 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.

Portanto, 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. Isso ocorre, 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. Com essa técnica, os desenvolvedores descrevem o comportamento esperado para a funcionalidade, e validam a construção da estória em cima desse comportamento.

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

Exemplo

Vamos voltar ao exemplo anterior para entendermos melhor a aplicação dos conceitos apresentados:

User Story

         COMO vendedor

         EU QUERO visualizar os produtos da loja

         PARA ver sua quantidade em estoque

Descrevendo em formato de tópicos:
O perfil vendedor deve:

• ter acesso ao sistema de gestão da loja;
• possuir permissão de geração de relatórios;
• possuir permissão a opção de relatório ‘’Produtos em Estoque’’.

Descrevendo utilizando cenários:

         Cenário 1: Gerar relatório de Produtos em Estoque

         Dado que o vendedor esteja logado no sistema da loja

             E possua permissão de geração de relatórios

         Quando ele clicar no menu ‘’Relatórios’’

            E ser apresentado a opção‘’Relatório de Produtos em Estoque’’

         Então ele deve conseguir gerar o relatório

Definição das Tarefas para a histórias de usuário (Tasks)

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

Exemplificando um pouco melhor sobre as tasks para o exemplo apresentado:

• Task 1 – Criar perfil de usuário ‘’vendedor’’;
• Task 2 – Criar permissão de geração de relatório;
• Task 3 – Criar permissão de ‘’Relatório de Produtos em Estoque’’.

Não existe uma regra quanto à forma que as tasks devem ser descritas, mas o principal é que elas sejam objetivas e claras, como uma espécie de roteiro de implementação.

Observação: devemos estar atentos às definições das tasks para que elas não sejam muito grandes. Pois, talvez, devemos transformá-las em uma nova user story. Ou seja, fazer uma quebra da história principal (como discutimos alguns tópicos acima).

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.

Como incluir o refinamento na minha rotina de trabalho?

Devemos ter muita clareza da importância em se realizar o refinamento das user story. E isso normalmente ocorre em dois momentos principais durante a sua definição para construção:

• Refinamento de negócio;
• Refinamento funcional e técnico.

Como sugestão para realização desse rito, é que exista uma cadência deles durante o andamento da sprint (esta cadência e o tempo de duração do rito, vai ser de acordo com a necessidade do seu time), crie eventos recorrentes! O objetivo principal é que utilizemos esse momento para um real entendimento das histórias que estamos construindo e eliminemos todas as dúvidas do time.

Neste rito é sempre importante a presença do Product Owner/ Product Manager, um desenvolvedor e um Product Design (de acordo com a configuração do seu time); cito isso pois assim você terá a visão de negócio, técnica e de experiência do usuário, conseguindo mitigar os riscos do produto de forma mais assertiva.

Outro ponto importante é trazer visibilidade desse processo para o time: inclua as tarefas de refinamento no kanban do seu time! Se planeje e organize as histórias que irá levar para o refinamento nos ritos, de acordo com as prioridades definidas para as sprints. Uma forma saudável é sempre estar com os itens das duas próximas sprints em processo de refinamento: da sprint seguinte em refinamento funcional e técnico e da sprint posterior em refinamento de negócio. Assim você sempre estará a frente do desenvolvimento, garantindo que quando as histórias entrarem para a trilha de delivery elas já estejam bem entendidas e com todos os critérios definidos para construção!

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

Baseado no que conversamos até aqui, sobre a escrita e refinamento de uma história de usuário, trago algumas dicas que considero importantes para se atentar ao definir nossas user story:

• 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 é responder as perguntas: 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. Isso deve ocorrer 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.

• Descreva os cenários – Utilize a técnica BDD 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 sobre história de usuário

Devemos descrever as histórias de usuário de forma objetiva, ágil e simples. Contudo, não cabe atribuir a elas detalhes técnicos, ou definições de como serão feitas. Nosso 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. Então, 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: Ela 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 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, sim, estão próximas do seu desenvolvimento e entrega para o usuário. 

Não existe receita de bolo

É importante dizer que não existe forma correta ou melhor para se escrever e refinar uma user story. Existe o que é funcional para o seu time! Esse modelo que trouxe neste artigo é um direcionador para que você se atente à 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ê?. É 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.

Se você tem interesse em saber mais sobre os assuntos abordados neste artigo, confira em nossa página de carreiras as vagas disponíveis para aplicação.

São dezenas de oportunidades para pessoas com interesse em diferentes áreas da tecnologia. Além das nossas vagas, você pode ouvir o nosso podcast e entender de perto da cultura dti na prática. Te esperamos lá!