Histórias de usuários com exemplos e um template

Resumo: Uma história do usuário é uma explicação informal e geral sobre um recurso de software escrita a partir da perspectiva do usuário final. Seu objetivo é articular como um recurso de software pode gerar valor para o cliente.

É tentador pensar que histórias de usuário são, grosso modo, requisitos de sistema do software. Mas não são.

Um componente-chave do desenvolvimento de software ágil é colocar as pessoas em primeiro lugar, e as histórias de usuário colocam os usuários finais reais sob os holofotes. Essas histórias usam linguagem não técnica para dar contexto à equipe de desenvolvimento e suas iniciativas. Depois de ler um exemplo de uma história de usuário, a equipe sabe por que está desenvolvendo o que está desenvolvendo e qual o valor que isso cria.

Mas o que são user stories? Histórias de usuários são um dos componentes principais de um programa ágil. Elas possibilitam uma estrutura centrada no usuário para o trabalho diário, o que impulsiona a colaboração, a criatividade e um produto melhor em geral.

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 explicação informal e geral sobre um recurso de software escrita a partir da perspectiva do usuário final ou cliente.

O objetivo de uma história de 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; também podem ser clientes internos ou colegas na empresa que dependem da 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 na estimativa e no planejamento de sprints, levando a 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 itens de trabalho 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 os objetivos organizacionais incorporados em epics e iniciativas.

Saiba mais sobre epics e iniciativas

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, mas uma coleção de histórias mantém o foco da equipe em resolver problemas de usuários reais.
  
• As histórias permitem a colaboração. Com a meta final definida, a equipe pode trabalhar em conjunto para decidir como atender melhor o 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 sobre a melhor maneira de resolver para chegar na 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 do usuário funcionam no Jira

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:

• A definição de "concluído" – A história em geral é "concluída" quando o usuário consegue realizar 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 realizadas 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.
  
• Ouça ao feedback – Fale com os usuários e capture o problema ou necessidade deles. Não há necessidade de fazer suposições quando você pode obter informações dos clientes.
  
• Tempo – O tempo é um assunto delicado. Muitas equipes de desenvolvimento evitam qualquer discussão sobre tempo, confiando apenas em estruturas de estimativa. Como as histórias devem ser possíveis de concluir em um sprint, as histórias que poderiam demorar semanas ou meses para serem concluídas devem ser divididas em histórias menores ou consideradas 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 os recursos 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.