Histórias de Usuário: Como Escrever (Com Exemplos e Template)

Histórias de usuário são descrições curtas, em linguagem simples, de uma funcionalidade narradas da perspectiva de quem vai usá-la. Elas são a espinha dorsal da maioria dos Backlogs de projetos ágeis e Scrum, e quando bem escritas, mantêm as equipes de desenvolvimento focadas em resultados reais para o usuário, em vez de requisitos técnicos abstratos.

O Que São Histórias de Usuário?

Uma história de usuário é uma descrição breve e informal de uma funcionalidade de software do ponto de vista do usuário final. Não é uma especificação técnica. É um marcador para uma conversa sobre o que um usuário precisa e por que essa necessidade é relevante para o produto.

O termo se popularizou com o Extreme Programming (XP) no final dos anos 1990 e foi formalizado por Mike Cohn em seu livro de 2004, User Stories Applied. Hoje, histórias de usuário são prática padrão em equipes ágeis, de startups de duas pessoas a divisões de produto corporativas.

Histórias de usuário mantêm as equipes honestas. Em vez de construir funcionalidades porque parecem tecnicamente interessantes, as equipes escrevem histórias de usuário para se manterem conectadas às pessoas para quem estão construindo. A história em si é curta por design. O valor vem da conversa que ela desencadeia entre product owners, desenvolvedores e partes interessadas.

Fatos Relevantes

• As histórias de usuário foram popularizadas por Kent Beck como parte do Extreme Programming (XP) no final dos anos 1990 e depois formalizadas no livro de Mike Cohn de 2004, User Stories Applied.
• De acordo com o 17º State of Agile Report (Digital.ai, 2023), 83% das equipes ágeis usam histórias de usuário como formato principal para capturar requisitos.
• Equipes que utilizam critérios de aceitação bem estruturados junto às histórias de usuário relatam 40% menos defeitos nas sprint reviews, segundo uma pesquisa de praticantes da Scrum Alliance de 2022.

O Template de História de Usuário

O formato clássico de história de usuário tem três partes. Você vai encontrá-lo em todo lugar:

Como [papel], quero [objetivo], para que [benefício].

Cada parte tem uma função específica.

Juntando tudo: "Como comprador de primeira viagem, quero salvar itens em uma lista de desejos, para que eu possa voltar a eles depois sem precisar pesquisar de novo."

Esse formato funciona porque força as equipes a pensarem em três coisas ao mesmo tempo: quem, o quê e por quê. Remova qualquer uma delas e a história fica muito mais difícil de priorizar ou estimar. Uma história sem a cláusula "para que" é apenas uma tarefa. Ela não diz qual valor você está criando, o que torna quase impossível decidir se vale a pena construir no momento do Sprint.

Histórias de Usuário vs. Épicos vs. Tarefas

As histórias de usuário ficam no meio de uma hierarquia de três níveis. Acertar a granularidade é fundamental quando você está conduzindo o sprint planning.

Épicos são grandes demais para construir em um único Sprint, então as equipes os dividem em histórias de usuário. As histórias têm tamanho para caber dentro de um Sprint. As tarefas são o trabalho técnico real que os desenvolvedores pegam e acompanham no quadro.

Um erro comum é escrever histórias em escopo de épico e depois se perguntar por que nada fica pronto. Se uma história leva mais de um Sprint para concluir, provavelmente é um épico disfarçado. Divida-a.

Os 3 Cs das Histórias de Usuário

Ron Jeffries introduziu o framework dos 3 Cs para descrever como as histórias de usuário funcionam na prática. O cartão é apenas o ponto de partida.

Cartão. Uma história de usuário é escrita tradicionalmente em um cartão-índice físico (ou equivalente digital). O cartão é curto por design: uma ou duas frases. Não é a especificação completa. É um lembrete de que uma conversa precisa acontecer.

Conversa. O cartão desencadeia uma discussão entre o product owner, os desenvolvedores e frequentemente as partes interessadas. Essa conversa é onde os requisitos reais são trabalhados. O cartão não contém todas as respostas. As pessoas contêm.

Confirmação. Depois que a conversa acontece, o time documenta os critérios de aceitação: as condições específicas que devem ser cumpridas para a história ser considerada concluída. Esses critérios são o que é testado e verificado antes de a história ser fechada.

A maioria dos times escreve o cartão e vai direto para a codificação. Isso é o inverso do correto. A etapa de conversa é onde a ambiguidade é resolvida, os casos extremos são descobertos e o entendimento compartilhado é construído. Histórias que pulam a conversa tendem a voltar para retrabalho.

Critérios INVEST para Boas Histórias de Usuário

Bill Wake introduziu o acrônimo INVEST para oferecer às equipes uma lista de verificação de qualidade para avaliar se uma história de usuário está bem formulada. Passe qualquer história por essa lista antes de incluí-la em um Sprint.

Faça uma verificação rápida do INVEST durante o refinamento do Backlog. Se uma história falhar em qualquer critério, não a inclua no planejamento ainda. Corrija-a primeiro. As falhas mais comuns são "não é pequena o suficiente" (deveria ser um épico) e "não é testável" (nenhum critério de aceitação escrito ainda).

Como Escrever uma História de Usuário

Escrever uma boa história de usuário exige mais do que preencher o template. Veja o processo que funciona de forma confiável.

Passo 1: Identifique sua persona de usuário

Quem realmente vai usar essa funcionalidade? Seja específico. "Usuários" não é uma persona. "Novos usuários que ainda não configuraram o pagamento" é. Quanto mais concreta a persona, mais fácil escrever uma história que reflita de fato as necessidades dela.

Se você ainda não tem personas formais, uma conversa rápida com sua equipe de suporte ao cliente vai revelar os tipos de usuário mais comuns em cerca de 20 minutos.

Passo 2: Nomeie o objetivo

O que o usuário está tentando realizar? Escreva como uma ação: "filtrar resultados de pesquisa por preço", "exportar dados como arquivo CSV", "receber um e-mail de confirmação após o checkout". Mantenha um objetivo por história. Se você se pegar escrevendo "e" no objetivo, provavelmente tem duas histórias.

Passo 3: Declare o benefício

Por que o usuário quer isso? Que resultado está buscando? Essa é a cláusula "para que". É também a parte mais ignorada. Não a ignore. O benefício diz ao time como é o sucesso, o que importa quando trade-offs surgem durante o desenvolvimento.

Passo 4: Adicione critérios de aceitação

Escreva as condições que a funcionalidade deve satisfazer para o time considerá-la concluída. Use linguagem simples ou o formato Given/When/Then (mais detalhes abaixo). Os critérios de aceitação não são opcionais. Sem eles, cada desenvolvedor do time tem um modelo mental ligeiramente diferente do que "concluído" significa.

Passo 5: Estime a história

Trabalhe com o time para dimensionar a história usando Story Points ou um método de estimativa relativa similar. Se a estimativa for alta (geralmente acima de 8 ou 13 em uma escala de Fibonacci), a história provavelmente é grande demais. Divida-a em partes menores antes do sprint planning.

Passo 6: Priorize e refine

Adicione a história ao Product Backlog e classifique-a por valor. Durante as sessões de refinamento do Backlog, revisite as histórias que entrarão no próximo Sprint para garantir que ainda sejam relevantes, estejam dimensionadas corretamente e tenham critérios de aceitação claros. Histórias que não foram refinadas recentemente frequentemente precisam de atualização antes de estarem prontas para o Sprint.

Exemplos de Histórias de Usuário

Aqui estão exemplos concretos em três tipos de produto comuns. Cada um segue o template padrão e inclui uma nota de aceitação resumida.

Observe que cada história nomeia um tipo de usuário específico, não um genérico "usuário". E cada cláusula de benefício explica a motivação real, não apenas uma reafirmação do objetivo.

Critérios de Aceitação e Definition of Done

Critérios de aceitação são as condições específicas que uma funcionalidade deve satisfazer para o time considerar a história de usuário concluída. São escritos antes do início do desenvolvimento, geralmente durante a etapa de conversa.

O formato mais comum é Given/When/Then (também chamado de sintaxe Gherkin):

• Given (dado que) algum contexto inicial ou pré-condição
• When (quando) o usuário realiza uma ação específica
• Then (então) um resultado específico ocorre

Exemplo para a história da lista de desejos:

Given que um comprador logado está visualizando a página de um produto When ele clica no botão "Salvar na Lista de Desejos" Then o item é adicionado à lista de desejos e uma notificação de confirmação aparece; o botão muda para "Salvo"

A Definition of Done (DoD) é diferente dos critérios de aceitação. Os critérios de aceitação são específicos para uma história. A DoD é um padrão de toda a equipe que se aplica a todas as histórias: testes unitários escritos, código revisado, implantado em staging, sem bugs críticos. Ambos precisam ser cumpridos antes de uma história ser fechada.

Não os confunda. Uma história pode atender todos os seus critérios de aceitação e ainda não atender a DoD se, por exemplo, nenhuma revisão de código aconteceu. Acompanhe os dois.

Erros Comuns ao Escrever Histórias de Usuário

Escrever da perspectiva do sistema, não do usuário. "O sistema deve enviar um e-mail" é um requisito técnico, não uma história de usuário. Reescreva: "Como novo usuário, quero receber um e-mail de boas-vindas após o cadastro, para saber que minha conta foi criada com sucesso."

Ignorar a cláusula de benefício. "Como usuário, quero filtrar resultados" diz quase nada ao time sobre prioridade ou valor. Por que o usuário quer filtrar? Que decisão vai tomar com os resultados filtrados? A cláusula "para que" é onde a informação real está.

Escrever épicos e chamá-los de histórias. "Como usuário, quero uma experiência completa de checkout" não é uma história. É uma área de funcionalidade. Divida em partes específicas e estimáveis: seleção de método de pagamento, confirmação de pedido, e-mail de recibo, etc.

Nenhum critério de aceitação antes do início do desenvolvimento. Histórias sem critérios de aceitação são convites abertos para retrabalho. Os desenvolvedores interpretam a ambiguidade da forma mais fácil de construir, não necessariamente o que o product owner tinha em mente. Escreva os critérios antes do início do Sprint.

Histórias demais para um Sprint. Equipes ágeis às vezes carregam o Backlog com mais histórias do que a equipe consegue realisticamente concluir. Isso leva a trabalho pela metade e um "burndown chart" inflado que nunca chega a zero. Use Story Points e a Velocity histórica para definir uma capacidade realista de Sprint.

Ignorar o passo de priorização MoSCoW. Nem todas as histórias de usuário são iguais. Algumas são obrigatórias, outras são opcionais. Sem priorização explícita, as equipes gastam tempo de Sprint em histórias de baixo valor enquanto o trabalho de alto valor espera.

Perguntas Frequentes

O que é uma história de usuário no contexto ágil?

Uma história de usuário é uma descrição curta, em linguagem simples, de uma funcionalidade da perspectiva do usuário, escrita no formato "Como [papel], quero [objetivo], para que [benefício]". É usada em equipes ágeis para capturar requisitos de uma forma que mantenha o foco no valor para o usuário, em vez de especificações técnicas. As histórias de usuário são normalmente armazenadas em um Product Backlog e incluídas em Sprints com base na prioridade.

Qual é a diferença entre história de usuário e épico?

Um épico é um grande conjunto de trabalho grande demais para ser entregue em um único Sprint. Uma história de usuário é uma fatia menor e entregável desse trabalho. Épicos são divididos em histórias de usuário. Por exemplo, "Experiência de checkout" é um épico. "Como comprador, quero salvar meus dados de pagamento para compras futuras" é uma história de usuário dentro dele.

Quem escreve histórias de usuário?

O product owner tipicamente escreve ou é responsável pelas histórias de usuário, mas as melhores histórias vêm da colaboração. Product owners trazem a perspectiva do negócio e do usuário. Desenvolvedores trazem o contexto técnico. Designers de UX trazem a pesquisa com usuários. As sessões de refinamento do Backlog são onde essas perspectivas se combinam para produzir histórias bem formuladas e estimáveis.

O que são Story Points?

Story Points são uma unidade de estimativa relativa que as equipes usam para dimensionar histórias de usuário. Em vez de estimar em horas (que variam por pessoa e frequentemente são imprecisas), as equipes comparam histórias entre si usando uma escala similar à de Fibonacci (1, 2, 3, 5, 8, 13). Uma história de 5 pontos é aproximadamente duas vezes mais complexa que uma de 2 pontos. Com o tempo, as equipes desenvolvem uma Velocity estável (pontos por Sprint), o que torna o sprint planning mais previsível.

O que significa INVEST em histórias de usuário?

INVEST é uma lista de verificação de qualidade para histórias de usuário: Independente (pode ser construída sem depender de outra história), Negociável (os detalhes podem mudar com base na conversa), Valiosa (entrega valor claro ao usuário), Estimável (o time consegue dimensioná-la), Small/Pequena (cabe em um Sprint) e Testável (tem critérios de aceitação verificáveis). Se uma história falha em qualquer um desses critérios, não está pronta para um Sprint.

---

Boas histórias de usuário não se escrevem sozinhas. Mas as equipes que dedicam tempo para acertá-las, nomeando personas de usuário reais, escrevendo cláusulas de benefício claras e anexando critérios de aceitação testáveis antes do início do desenvolvimento, passam menos tempo em retrabalho e mais tempo entregando coisas que importam.

Comece com uma história para o item de maior prioridade no seu Backlog atual. Aplique o template, faça a verificação INVEST e escreva dois ou três critérios de aceitação. Esse é o hábito. Construa a partir daí.

Para frameworks relacionados, veja a estrutura analítica do projeto para decompor o escopo do projeto, o sprint planning para incluir histórias nos Sprints, e o Scrum vs Kanban se você está decidindo qual Workflow se encaixa melhor no seu time.