Depois de falarmos muito sobre o Framework Scrum e sobre o Método Kanban, está na hora de falar um pouco mais sobre o que é uma User Story e como elas compõem um Product Backlog.

A User Story ou História de Usuário, surgiu com o Extreme Programming em 1998, no qual foram descritas apenas como uma das “peças do jogo” que são utilizadas durante o planejamento e que naquela época serviam apenas como uma alternativa para os casos de uso.

Com o passar dos anos as histórias de usuário evoluíram e se tornaram uma das principais ferramentas utilizadas no desenvolvimento de software, sendo que atualmente é possível utilizá-las em qualquer desenvolvimento de produtos.

Já sabemos que durante um projeto que utilize Métodos Ágeis a ideia é dividir grandes partes de um desenvolvimento em pedaços muito menores para manter o ritmo de entregas frequentes durante as sprints, está atividade é realizada pelo Product Owner através da escrita de diversas histórias de usuário.

Antes de te apresentar o que é e o que não é uma User Story, vamos descobrir o significado de cada uma das palavras que compõem o termo:

• Story / História – Narrativa de ficção, oral ou escrita.
• User / Usuário – Pessoa que faz uso de um produto (produtos físicos ou digitais).

Em resumo, é possível dizer que uma história de usuário é uma narrativa escrita sobre a utilização de um produto.

É importante que você saiba que a User Story não faz parte do Framework Scrum ou do Método Kanban, em nenhum momento ela é descrita dentro dos guides como uma prática oficial, mas é deixado como livre a sua implementação conforme necessidade do seu projeto.

O que é uma User Story?

Existem diversas dúvidas sobre o que é uma história de usuário e sobre o que realmente ela agrega de valor durante um desenvolvimento ágil de um produto, portanto vou te apresentar alguns pontos que levantei e que ficará mais simples de você entender:

• Permite obter um conhecimento das personas e suas necessidades, descrevendo estas necessidades de forma simples e leve.
• Permite que o time de desenvolvimento tenha flexibilidade e criatividade na criação do produto.
• Possui uma linguagem fácil de ser entendida por todas as partes interessadas do projeto.
• Facilidade e agilidade no refinamento das tarefas, permitindo que as estimativas dos esforços sejam mais concretas.
• Possibilita uma estrutura centrada no trabalho diário que será realizado pelo usuário final.

Como você pode perceber o mais interessante na utilização de User Stories é que ela é focada nas necessidades reais e práticas do usuário, mais para frente quando falarmos sobre a sua estrutura você conseguirá entender melhor.

O que não é uma User Story?

Sempre tive muitas dúvidas sobre o que não é uma User Story, já que existem outros conceitos muito parecidos com esta prática. Abaixo segue alguns pontos que você consegue identificar da próxima vez que for criar a sua própria história:

• Apesar de poder conter um ou mais artefatos de requisitos, a história em si não é uma especificação de requisitos.
• Uma História de Usuário não é a mesma coisa que um Caso de Uso, as duas possuem objetivos diferentes.
• Não contem uma linguagem técnica onde as pessoas não entendem o que está descrito.
• Não é uma documentação oficial do projeto ou produto.
• Não é apenas um texto descrito em um post-it que mostra o que o desenvolvedor deve fazer.

Estrutura de uma boa História de Usuário

A estrutura de uma História de Usuário pode variar de empresa para empresa e até mesmo por quem está escrevendo ela, mas existem três aspectos principais que todas elas devem conter:

1. Como [Persona/Ator]: É o usuário interessado naquela funcionalidade do produto que está sendo desenvolvido.
2. Quero [Necessidade/Ação]: É a ação que o usuário pretende realizar para alcançar o seu objetivo dentro do produto.
3. Para que [Objetivo/Funcionalidade]: É o resultado que o usuário espera que aconteça após a ação que ele realizou.

Quando colocamos isto em prática é possível perceber que estamos utilizando sentenças narrando a utilização do requerimento, como no exemplo:

Como [Persona/Ator], quero [Necessidade/Ação] para que eu possa [Objetivo/Funcionalidade].

Como CEO, quero saber qual o custo por produto, para que eu possa decidir qual fornecedor iremos contratar.

Em alguns casos ainda é colocado algumas informações gerais sobre a história de usuário que está sendo criada, principalmente em grandes projetos. Nestas informações gerais você pode acrescentar um número identificador, o projeto ou iniciativa e até mesmo dar um título a história criada.

Outro ponto que você deve ficar ligado é nos Critérios de Aceitação, que são critérios para que a história seja aceita e dada como entregue pelos nossos clientes, estes critérios podem conter um conjunto de instruções ou um checklist, com os resultados esperados de aprovação ou reprovação.

Lembre-se que a User Story é apenas o começo de um projeto, quando elas forem levadas adiante para o time de desenvolvimento será necessário detalha-las em tarefas para que seja considerada suficiente o bastante.

Quero deixar algumas dicas para a próxima vez que você for escrever uma história de usuário, utilize uma definição de concluído como objetivo, pense em quais as tarefas serão criadas, estude bem em quais serão as personas, ouça feedback de pessoas que possuam a necessidade da história que está sendo escrita e converse com o seu time de desenvolvimento sobre o tempo que eles irão levar em cada uma das histórias.

E aí, você já criou alguma História de Usuário? Me conta aqui nos comentários 😉

Se preferir outro lugar, você consegue falar comigo também pelo Instagram ou pelo LinkedIn.