Uma história de usuário é a menor unidade de trabalho em uma estrutura ágil. É um objetivo final, não um recurso, expresso da perspectiva do usuário do software.

Uma história do usuário é uma descrição informal e geral sobre uma função de software escrita a partir da perspectiva do usuário final ou cliente. O objetivo de uma história do usuário é articular como uma única tarefa pode oferecer um determinado valor ao cliente.

Observe que "clientes" não precisam ser usuários finais externos no sentido tradicional. Eles também podem ser clientes internos ou colegas de sua organização que dependem de sua equipe.

Histórias de usuários são algumas frases em linguagem simples que delineiam o resultado desejado. Elas não entram em detalhes. Os requisitos são adicionados mais tarde, assim que a equipe entrar em acordo. Quer saber como escrever histórias de usuários? Uma boa forma de fazer isso é com exemplos de histórias de usuários. Histórias combinam perfeitamente com estruturas ágeis como Scrum e Kanban.

No Scrum, histórias de usuários são adicionadas a sprints e “queimadas” ao longo do sprint. Nas equipes Kanban, as histórias de usuários são colocadas no backlog e passam por todo o fluxo de trabalho.

É esse trabalho com as histórias de usuários que ajuda as equipes Scrum a melhorar a estimativa e o planejamento de sprints, gerando previsões mais precisas e maior agilidade. Graças às histórias, as equipes Kanban aprendem a gerenciar o trabalho em andamento (WIP) e podem refinar ainda mais os fluxos de trabalho.

Histórias de usuários também são os blocos de construção de estruturas Ágeis maiores, como epics e iniciativas. Epics são tickets grandes divididos em um conjunto de histórias, e vários epics compõem uma iniciativa.

Essas estruturas maiores garantem que o trabalho diário da equipe de desenvolvimento (nas histórias) contribua para as metas organizacionais incorporadas em epics e iniciativas. Você pode aprender mais sobre epics e iniciativas aqui!

Para equipes de desenvolvimento novatas na metodologia ágil, as histórias de usuários às vezes parecem uma etapa adicional. Por que não apenas dividir o projeto grande (o epic) em uma série de etapas e pronto? Porque as histórias dão à equipe um contexto importante e associam as tarefas ao valor que elas agregam.

As histórias do usuário trazem vários benefícios:

• As histórias mantêm o foco no usuário. Uma lista de afazeres mantém o foco da equipe nas tarefas que precisam ser realizadas. No entanto, um conjunto de histórias mantém o foco na solução de problemas de usuários reais. 

• As histórias possibilitam a colaboração. Com a meta final definida, a equipe pode trabalhar em conjunto para decidir como atender melhor ao usuário e alcançar essa meta. 

• As histórias impulsionam soluções criativas. As histórias incentivam o pensamento crítico e criativo da equipe em relação à melhor maneira de solucionar um problema para atingir uma meta final. 

• As histórias criam ritmo. Com cada história resolvida, a equipe de desenvolvimento experimenta pequenos desafios e pequenas vitórias, criando um ritmo. 

Veja como as histórias de usuários funcionam no Jira Software

Depois de escrever uma história, ela deve ser integrada ao fluxo de trabalho. Em geral, a história é escrita pelo proprietário do produto, gerente de produto ou gerente de programa e enviada para revisão.

Durante uma reunião de planejamento de sprint ou iteração, a equipe decide quais histórias vão ser trabalhadas nesse sprint. Então, as equipes discutem os requisitos e a funcionalidade que cada história de usuário requer. Esta é uma oportunidade para a equipe ser técnica e criativa na implementação da história. Assim que forem combinados, esses requisitos são adicionados à história.

Outro passo comum nessa reunião é dar uma pontuação para as histórias com base em sua complexidade ou tempo de conclusão. As equipes podem usar tamanhos de camisetas, a sequência de Fibonacci ou o Planning Poker para fazer estimativas adequadas. Uma história deve ser concluída em um sprint, então, à medida que a equipe especifica cada história, precisa decompor histórias que ultrapassariam esse prazo de conclusão.

Considere o seguinte ao escrever histórias do usuário:

• Definição de "concluído" — Em geral, a história é considerada "concluída" quando o usuário consegue fazer toda a tarefa descrita. Mas não esqueça de definir bem o que seria isso. 

• Definição de subtarefas ou tarefas — Decida quais etapas específicas precisam ser concluídas e quem é responsável por cada uma delas. 

• Personas do usuário — Para quem? Se existirem diversos usuários finais, considere criar diversas histórias. 

• Etapas ordenadas — Escreva uma história para cada etapa de um processo maior. 

• Leve o feedback a sério — Converse com os usuários para saber que problemas ou necessidades eles têm. Para que tentar adivinhar as histórias quando você pode obter informações diretamente dos clientes? 

• Tempo: esse é um assunto delicado. Muitas equipes de desenvolvimento evitam qualquer discussão sobre tempo, confiando apenas em estruturas de estimativa. É possível concluir as histórias em apenas um sprint. Por isso, aquelas que podem levar semanas ou meses para serem concluídas devem ser divididas em histórias menores ou consideradas como um epic. 

Uma vez que as histórias do usuário estiverem definidas com clareza, verifique se elas estão visíveis para toda a equipe.

As histórias do usuário em geral são expressas em uma frase simples, como as seguintes:

"Como [persona], eu [quero], [para que]."

Detalhando: 

• "Como [persona]": para quem estamos criando? Não estamos em busca de apenas um cargo, estamos em busca da persona da pessoa. Max. Nossa equipe deve ter um entendimento comum de quem é Max. A gente espera ter entrevistado vários Max. A gente entende como essa pessoa trabalha, como ela pensa e o que ela sente. A gente tem empatia pelo Max.

• "Quer": aqui descrevemos a intenção da pessoa, não as funções que ela usa. O que ela quer alcançar mesmo? Esta declaração não deve tratar de implementação — se estiver descrevendo qualquer parte da IU e não a meta do usuário, você entendeu errado.

• "Para que": como a vontade imediata dele de fazer algo se encaixa no cenário geral? Qual é o benefício geral que ele quer alcançar? Qual é o grande problema que precisa de solução?

Por exemplo, é possível escrever histórias do usuário assim:

• Como Max, eu quero convidar meus amigos, para que a gente possa aproveitar este serviço juntos.

• Como Sascha, eu quero organizar meu trabalho, para que eu me sinta mais no controle. 

• Como gerente, eu quero conseguir entender o progresso dos meus colegas, para que eu possa ter relatórios melhores dos nossos acertos e falhas. 

Esta estrutura não é necessária, mas é útil para definir o "pronto". Quando essa persona pode obter seu valor desejado, então a história está completa. As equipes podem e devem definir e seguir a sua própria estrutura.

Histórias de usuários descrevem o motivo e o que há por trás do trabalho diário dos membros da equipe de desenvolvimento, muitas vezes expressos como persona + necessidade + propósito. Compreender o papel das histórias como fonte de verdade para o que sua equipe está entregando, mas também como motivo desse trabalho, é fundamental para um processo tranquilo.

Comece avaliando o próximo, ou mais urgente, projeto grande (por exemplo, um epic). Divida em histórias menores de usuários e trabalhe com a equipe de desenvolvimento para refinamento. Assim que as histórias estiverem prontas, onde toda a equipe possa ver, você está pronto para começar a trabalhar.