histórias de usuário
Share on facebook
Share on twitter
Share on linkedin

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

Felipe Soares

Felipe Soares

Product Owner

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!

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: 

Como, Quem, Eu Quero, O Quê,Para, Por Quê?

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:

Como, Quem, O quê?, Por Quê?

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:  

Ivest: História de Usuário

  • 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. Esses pontos que antecedem a minha história principal, fazem parte dela e precisam ser pensados.

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 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. 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 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 é listada a escrita do contexto da história e é representada a escrita do cenário correspondente. 

História de usuário

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, também devem ser definidas 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 do que precisa ser feito em caráter, na maioria das vezes, técnicos. Normalmente são definidas pelo próprio time de desenvolvimento.

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’’.

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

Observação: É importante se atentar às definições das tasks para que elas não sejam muito grandes, pois talvez elas devam ser encaradas como uma nova user story, representando 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: 

  • 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. 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 que precisam ser atendidas com aquela história.  
  • 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. 

História De Usuário

Assimilando os conceitos sobre história de usuário

A descrição das histórias de usuário devem ser escritas de forma objetiva, ágil e simples. Não cabe a elas 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. 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. 

CTA episódio 88

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.

Venha ser dti vagas de carreiras

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á!

Preencha seus dados para receber nossa newsletter!

Ficou com dúvidas?

contato@dtidigital.com.br
R. Antônio de Albuquerque, 330 – 14° andar
Savassi, Belo Horizonte – MG, 30112-010

Cuidado

Nós utilizamos cookies e outras tecnologias semelhantes para analisar sua experiência no site e personalizar conteúdos e anúncios durante sua navegação. Ao navegar pelo site, você autoriza a DTI Digital a realizar tal monitoramento. Conheça nossa Política de Privacidade.

you are being redirected to a page in portuguese, do you want to continue?