Histórias de usuários com exemplos e template

Histórias de usuários são tarefas de desenvolvimento expressas, em geral, como "persona + necessidade + propósito". 

Max Rehkopf Max Rehkopf
Buscar tópicos

É tentador pensar que histórias de usuários 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ários colocam os usuários finais reais sob os holofotes. Histórias usam linguagem não técnica para dar contexto à equipe de desenvolvimento e suas iniciativas. Depois de ler uma história de usuário, a equipe sabe por que está desenvolvendo o que está desenvolvendo e qual o valor que isso cria. 

Histórias de usuários são um dos componentes principais de um programa ágil. Elas ajudam a fornecer 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.

O que são histórias de usuário ágeis?

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.

O objetivo de uma história de usuário é articular como uma única tarefa pode oferecer um determinado um 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.

Histórias se encaixam perfeitamente em 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 executadas por meio do fluxo de trabalho. É esse trabalho com as histórias de usuários que ajuda as equipes scrum a melhorar na estimativa e 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 – work in progress) e podem refinar ainda mais seus 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 grandes itens de trabalho 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 lojas) contribua para os objetivos organizacionais incorporados em epics e iniciativas.

Saiba mais sobre epics e iniciativas

Epics ágeis versus histórias versus temas | Coach Agile Atlassian

Por que criar histórias de usuários?

Para equipes de desenvolvimento novas 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.

Histórias de usuários oferecem uma série de benefícios-chave:

  • Manter o foco no usuário. Uma lista de tarefas mantém a equipe focada em tarefas que precisam ser eliminadas, mas uma coleção de histórias mantém a equipe concentrada em resolver problemas para usuários reais.
     
  • Permitir a colaboração. Com o objetivo final definido, a equipe pode trabalhar em conjunto para decidir a melhor forma de atender o usuário e atingir esse objetivo.
     
  • Inspirar soluções criativas. Histórias encorajam a equipe a pensar de maneira crítica e criativa sobre a melhor forma de alcançar um objetivo final.
     
  • Aumentar a motivação. A cada história, a equipe de desenvolvimento enfrenta um pequeno desafio e uma pequena vitória, aumentando a motivação. 

Trabalhando com histórias de usuários

Depois de escrever uma história, ela deve ser integrada ao fluxo de trabalho. Geralmente, 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 vão ultrapassar esse prazo de conclusão.  

Como escrever histórias de usuário

Considere o seguinte ao escrever histórias de usuários:

  • Definição de “Concluído” — a história geralmente é “concluída” quando o usuário pode concluir a tarefa delineada, mas é preciso definir o que isso significa em cada caso.
     
  • Delineie subtarefas ou tarefas — decida quais etapas precisam ser concluídas e quem é responsável por cada uma delas.
     
  • Personas do usuário — para quem? Se houver vários usuários finais, pode ser o caso de criar várias histórias.
     
  • Etapas ordenadas — escreva uma história para cada etapa em um processo maior.
     
  • Ouça comentários — fale com seus usuários e apreenda o problema ou a necessidade de suas palavras. Não há necessidade de adivinhar histórias quando se pode obtê-las de seus clientes.
     
  • Prazos — prazos são um assunto delicado, que muitas equipes de desenvolvimento evitam discutir por completo, confiando em seus quadros de estimativa. Como é necessário que as histórias possam ser completadas em um sprint, as que talvez levem semanas ou meses para serem concluídas devem ser divididas em histórias menores ou, até mesmo, ser consideradas epics por si sós.
     

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

Template e exemplos de histórias de usuários

Histórias de usuários muitas vezes são expressas em uma frase simples, estruturada da seguinte forma:

“Como uma [persona], eu [quero], [de modo que]”.

Dividindo isso: 

  • “Como uma [persona]”: Para quem estamos construindo isso? Não estamos só atrás de um cargo, estamos atrás da personalidade da pessoa – Max, por exemplo. A equipe deve ter uma compreensão compartilhada de quem Max é. Esperamos ter entrevistado Max o bastante. Entendemos como essa pessoa trabalha, como pensa e o que sente. Temos empatia pelo Max.
  • “Quero”: Aqui estamos descrevendo sua intenção — não os recursos que ele usa. O que é que ele está realmente tentando alcançar? Esta instrução deve ser livre de implementação — se você estiver descrevendo qualquer parte da interface do usuário e não qual é o objetivo do usuário, você não entendeu o objetivo.
  • “De modo que”: como é que o seu desejo imediato de fazer algo assim se encaixa no seu quadro maior? Qual é o benefício geral que ele está tentando alcançar? Qual é o grande problema que precisa ser resolvido?

Por exemplo, histórias de usuários podem ser assim:

  • Eu, Max, eu quero convidar meus amigos, de modo que possamos desfrutar desse serviço juntos.
  • Eu, Sascha, eu quero organizar meu trabalho, para me sentir mais no controle. 
  • Eu, gerente, eu quero conseguir entender o progresso dos meus colegas, de modo que eu possa relatar melhor nossas vitórias e fracassos. 

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.

Introdução às histórias de usuários ágeis

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 seu papel como fonte de verdade para o que sua equipe está entregando, mas também o motivo desse trabalho, é fundamental para um processo tranquilo.

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

a seguir
Estimation