Como escrever histórias de usuário (com exemplos e critérios de aceitação)

Uma história de usuário é uma descrição curta de uma funcionalidade do ponto de vista do usuário: “Como [tipo de usuário], quero [objetivo] para que [motivo].” Abaixo dela, você escreve os critérios de aceitação, algumas condições específicas que precisam ser verdadeiras para que a história seja considerada concluída. Mantenha cada história pequena o bastante para ser construída e testada de uma vez, e escreva os critérios de forma que qualquer pessoa consiga verificá-los.

Histórias de usuário ficaram populares com equipes ágeis de software, mas são igualmente úteis quando você constrói sozinho com um construtor de apps com IA. Uma boa história é um bom prompt.

O formato

Uma história de usuário tem três partes:

Como [quem], quero [o quê] para que [por quê].

Quem é um tipo específico de usuário: um visitante de primeira viagem, um membro pagante, uma recepcionista de clínica, um administrador. Não “o usuário”.
O quê é aquilo que a pessoa quer fazer, com as palavras dela. Não como a tela funciona.
Por quê é o resultado que ela busca. É a parte que as pessoas costumam pular, e a que impede você de construir a coisa errada.

Exemplo:

Como membro da academia, quero cancelar uma reserva de aula pelo celular para que alguém da lista de espera possa ocupar minha vaga e eu não seja cobrado por falta.

O “por quê” diz duas coisas que o “o quê” não dizia: precisa funcionar no celular, e a lista de espera e as regras de taxa estão envolvidas.

Critérios de aceitação

A história diz o que se quer. Os critérios de aceitação dizem quando está pronto. Eles devem ser específicos o bastante para que duas pessoas concordem se cada um passa ou não.

Uma forma comum de escrevê-los é Dado / Quando / Então:

Dado uma situação inicial
Quando o usuário faz algo
Então este é o resultado

Para a história da reserva na academia:

Dado que tenho uma reserva marcada para mais de 12 horas à frente, quando toco em Cancelar e confirmo, então a reserva é removida e vejo “Reserva cancelada”.
Dado que cancelo uma reserva e a aula tem lista de espera, quando o cancelamento é salvo, então a primeira pessoa da lista de espera recebe a vaga e um e-mail.
Dado uma reserva a menos de 12 horas, quando toco em Cancelar, então vejo que uma taxa de cancelamento tardio se aplica antes de confirmar.
Dado que estou em uma tela com largura de celular, então o botão Cancelar fica visível sem rolar para o lado.

Uma lista de verificação simples também funciona, desde que cada item seja testável. “Cancelar é fácil” não é testável. “Cancelar leva no máximo dois toques a partir da lista de reservas” é.

Passo a passo: escrevendo uma boa história

Passo 1: comece por um usuário real e um problema real

Escolha um tipo de usuário e algo com que ele tem dificuldade hoje. Se você fez entrevistas com clientes, use as palavras deles. “Eu sempre esqueço de cancelar e sou cobrado” é um ponto de partida melhor do que “adicionar funcionalidade de cancelamento”.

Passo 2: escreva a história em uma linha

Preencha o modelo. Se você não consegue escrever um “para que” convincente, pergunte-se se a funcionalidade é realmente necessária.

Passo 3: adicione de três a seis critérios de aceitação

Cubra primeiro o caso de sucesso principal e depois as variações importantes: um papel diferente, um estado vazio, um limite, um erro. Se você estiver escrevendo mais de seis, a história provavelmente está grande demais.

Passo 4: anote o que está fora do escopo

Uma linha economiza muita ida e volta: “Fora do escopo: reembolsos de aulas pagas; administradores cancelando em nome de membros.” Isso impede que a história cresça enquanto você constrói.

Passo 5: confira com o INVEST

INVEST é uma lista de verificação comum para boas histórias. Uma história deve ser:

Letra	Significa	Teste rápido
I	Independente	Pode ser construída sem esperar por outra história
N	Negociável	Descreve a necessidade, não um design fixo
V	Valiosa	Um usuário notaria se fosse lançada
E	Estimável	Você consegue estimar, aproximadamente, o seu tamanho
S	Pequena	Construída e testada de uma vez
T	Testável	Cada critério de aceitação pode ser verificado

Você não precisa pontuar cada história. Isso é mais útil quando uma história parece errada e você quer saber o motivo.

Exemplos bons e ruins

História fraca	Problema	História melhor
Como usuário, quero um painel.	Sem usuário específico, sem motivo, não testável	Como dono de loja, quero ver os pedidos e a receita de hoje em uma única tela para saber de relance se o dia está indo bem.
Como administrador, quero que o banco de dados tenha uma coluna de status.	Descreve a implementação, não uma necessidade	Como administrador, quero marcar pedidos como enviados para que os clientes parem de mandar e-mails perguntando onde estão.
Como cliente, quero gerenciar minha conta.	Grande demais: cobre muitas funcionalidades	Como cliente, quero alterar meu e-mail para que os recibos cheguem na minha nova caixa de entrada.
Como visitante, quero que o site seja rápido.	Não é uma história; é uma qualidade que todos precisam	Escreva como critério em cada história, ou como uma meta de desempenho separada.

Como dividir uma história grande demais

Histórias grandes são onde os projetos travam. Formas comuns de dividir:

Por papel do usuário. Membros cancelam as próprias reservas; a equipe cancela as de qualquer um.
Por etapa do fluxo. Navegar pelas aulas; reservar uma aula; receber um lembrete.
Caso simples primeiro. Cancelar uma aula gratuita agora; tratar taxas e reembolsos em uma história posterior.
Por variação de dados. Suportar primeiro uma unidade; várias depois.
Caminho feliz, depois erros. Construa primeiro o funcionamento básico e depois trate casos como aulas lotadas, passes vencidos, e assim por diante.

Cada parte ainda deve ser algo que um usuário poderia usar e perceber.

Usando histórias de usuário como prompts

Uma história de usuário com critérios de aceitação é muito próxima de um bom prompt para um construtor de apps com IA. Ela dá à IA o quem, o quê, o porquê e uma definição de pronto. Envie uma história por mensagem:

Como membro da academia, quero cancelar uma reserva de aula pelo celular para que alguém da lista de espera possa ocupar minha vaga. Critérios de aceitação:

Cancelar aparece em cada reserva em Minhas Reservas, com uma etapa de confirmação.

Cancelar mais de 12 horas antes da aula apenas remove a reserva.

Com menos de 12 horas, mostre “Aplica-se taxa de cancelamento tardio de R$ 25” antes de confirmar, e registre a taxa na reserva.

Se a aula tiver lista de espera, a primeira pessoa recebe a vaga e um e-mail.

Funciona em uma tela com largura de celular. Fora do escopo: reembolsos, equipe cancelando por membros. Construa isto e depois verifique cada critério na prévia e me diga quais passam.

Você também pode pedir à IA que rascunhe histórias a partir de uma ideia bruta e depois editá-las você mesmo:

Esta é a ideia do meu app: [duas ou três frases]. Escreva as histórias de usuário para uma primeira versão, agrupadas por tipo de usuário, cada uma com de 3 a 5 critérios de aceitação Dado/Quando/Então. Marque quais são essenciais para o lançamento e quais podem esperar.

Sempre leia e edite o resultado. A IA não conhece seus usuários; você conhece.

Os critérios de aceitação também servem como o seu plano de testes. Quando a história estiver construída, percorra você mesmo cada critério. Nosso guia sobre como testar seu app antes do lançamento se apoia nisso.

Onde as histórias de usuário se encaixam com outros documentos

Um documento de requisitos de produto descreve o produto inteiro: o problema, os usuários, o escopo. As histórias de usuário são as peças detalhadas dentro dele. Veja como escrever um PRD com IA.
Um relato de bug descreve algo quebrado em relação a uma história que já foi construída. Veja como escrever um bom relato de bug.
Um MVP é o menor conjunto de histórias que entrega o valor central. Veja o que é um MVP.

Erros comuns

“Como usuário…” Vago demais. Nomeie o tipo real de usuário.
Pular o “para que”. Sem o motivo, você não consegue fazer trade-offs sensatos.
Escrever a solução em vez da necessidade. “Quero um menu suspenso” trava um design antes que alguém tenha pensado nele.
Critérios que não podem ser testados. “Fácil”, “rápido” e “intuitivo” são desejos, não critérios.
Histórias que na verdade são épicos. “Gerenciar minha conta” são dez histórias.
Escrever todas as histórias de antemão. Escreva as próximas poucas em detalhe; mantenha o resto como frases curtas até chegar nelas.

Histórias na Mythex

Na Mythex, o modo Plano é um bom lugar para transformar uma ideia em histórias: o agente discute a abordagem antes de editar qualquer coisa. Quando uma história estiver pronta, mude para Construir e cole-a, uma história por mensagem. Depois de cada uma, /test pode percorrer a prévia e verificar o fluxo, e você pode voltar qualquer resposta com Voltar para este ponto se algo deu errado. Veja prompts eficazes na documentação e nosso guia sobre como escrever prompts para construtores de apps com IA.

Lista de verificação de história de usuário

Nomeia um tipo específico de usuário
Descreve uma necessidade, não um design
Inclui um “para que” real
Tem de três a seis critérios de aceitação testáveis
Cobre pelo menos um caso extremo ou erro
Declara o que está fora do escopo
Pequena o bastante para ser construída e testada de uma vez
Critérios verificados após a construção, um a um

Perguntas

Qual é o formato de uma história de usuário?

O modelo mais comum é: Como [tipo de usuário], quero [algum objetivo] para que [algum motivo]. Em seguida vêm os critérios de aceitação, uma lista curta de condições que precisam ser verdadeiras para que a história seja considerada concluída.

O que são critérios de aceitação?

Critérios de aceitação são condições específicas e testáveis que definem quando uma história de usuário está concluída. Costumam ser escritos no formato Dado / Quando / Então: dada uma situação inicial, quando o usuário faz algo, então acontece um resultado específico.

Qual deve ser o tamanho de uma história de usuário?

Pequena o bastante para ser construída e testada de uma vez, e ainda assim valiosa por si só. Se uma história tem mais de cinco ou seis critérios de aceitação ou cobre várias telas, divida-a por papel do usuário, por etapa do fluxo ou por caso simples primeiro, deixando os casos extremos para depois.

Histórias de usuário são úteis ao construir com IA?

Sim. Uma história de usuário com critérios de aceitação está próxima de um prompt ideal: diz para quem é a funcionalidade, o que a pessoa precisa e exatamente como verificar se ela funciona. Enviar uma história por mensagem também mantém as mudanças da IA pequenas e fáceis de testar.