Exemplos de histórias de usuário: 16 histórias comentadas, boas e ruins

Dezesseis exemplos de histórias de usuário nas áreas de autenticação, comércio eletrônico, dispositivos móveis, APIs e bugs — cada um deles anotado, com as versões incorretas apresentadas ao lado de suas reescritas, para que a diferença fique visível.

Dezesseis exemplos de histórias de usuário, extraídos dos domínios em que as equipes realmente atuam: autenticação, comércio eletrônico, dispositivos móveis, APIs, bugs e ferramentas internas. Cada uma delas vem acompanhada de anotações — não apenas o que a história diz, mas também por que as cláusulas de função e benefício são essenciais. Quatro delas são deliberadamente ruins e apresentadas ao lado de suas versões revisadas, pois a maneira mais rápida de aprender o formato é observar quando ele falha.

Se o formato em si for novo para você, comece por o que é uma user story? — resumindo, todas as histórias aqui seguem o formato “Como [função], eu quero [objetivo], para que [benefício]”, e toda história de qualidade poderia ir direto para o refinamento e uma rodada de planning poker.

Autenticação e contas

1. Faça login

Como cliente recorrente, quero fazer login com meu e-mail e senha para poder ver meu histórico de pedidos.

Por que funciona: a função é específica. “Cliente recorrente” indica que essa pessoa tem uma conta, já fez pedidos anteriormente e tem um motivo para voltar — três fatos que um designer e um testador podem aproveitar. “Como usuário” não teria transmitido nenhum desses aspectos.

2. Redefinição de senha

Como usuário cujo acesso foi bloqueado, quero redefinir minha senha na tela de login, para que eu possa acessar minha conta novamente sem precisar entrar em contato com o suporte.

Por que funciona: a cláusula de benefício menciona um custo real. Cada reinicialização que passa pelo suporte representa um custo mensurável, portanto, essa questão pode ser priorizada em relação a outras com base em evidências, e não em impressões. Observe o que a frase não menciona — validade do token, limites de taxa, o modelo de e-mail. Esses detalhes devem constar nos critérios de aceitação, redigidos quando a equipe os refinar:

  • Um e-mail de redefinição é enviado em até dois minutos após a solicitação.
  • O link de redefinição expira após uma hora e pode ser usado uma única vez.
  • O formulário fornece a mesma resposta, independentemente de o e-mail existir ou não (sem enumeração de contas).

3. A história circular

Como usuário, quero fazer login para poder acessar o aplicativo.

Por que isso não funciona: todos os espaços estão preenchidos, mas nada é dito. O personagem não é ninguém em particular, e o benefício apenas reafirma o objetivo; portanto, a oração com “para que” poderia ser suprimida sem perda de informação. Uma história como essa passa na verificação de formato, mas ignora todo o raciocínio que o próprio formato visa exigir.

A reescrita:

Como membro do projeto que está voltando no meio do sprint, quero acessar o painel que vi pela última vez depois de fazer login, para não precisar navegar até lá todas as manhãs.

Ora, há uma pessoa, um momento e um benefício que alguém poderia ponderar em relação a outro trabalho.

Comércio eletrônico

4. Persistência do carrinho

Como consumidor que está navegando pelo site durante meu intervalo de almoço, quero que meu carrinho mantenha os itens selecionados quando eu voltar à noite, para que eu não precise procurar tudo de novo.

Por que funciona: o papel transmite um cenário. “Navegando na internet durante o intervalo para o almoço” explica por que os carrinhos são abandonados no meio do processo, o que indica à equipe que a janela de persistência relevante é de horas, e não de segundos. Um papel bem escolhido transmite o contexto em uma única frase.

5. Finalização da compra como visitante

Como estou comprando pela primeira vez, quero finalizar a compra sem criar uma conta, para poder concluir a transação antes de mudar de ideia.

Por que funciona: apresenta uma proposta de produto (as contas são opcionais) e destaca o benefício de forma sincera — a hesitação impede as primeiras compras. Histórias tão claras também revelam divergências logo no início: se a empresa deseja que todos os compradores tenham uma conta, essa discussão ocorre na fase de refinamento, e não no pull request.

6. A métrica vestindo uma fantasia de conto

Como consumidor, quero um processo de finalização de compra mais rápido e mais simples, para que a taxa de conversão aumente.

Por que isso não funciona: por dois motivos. “Mais rápido, mais limpo” não é uma capacidade que qualquer um possa desenvolver ou testar, e “a conversão melhora” é o benefício para a empresa, não para o consumidor — nenhum consumidor quer conversão. Trata-se do trabalho de um trimestre comprimido em uma frase, o que a torna uma epopeia, não uma história.

A reescrita (uma parte dela):

Como comprador pelo celular, quero que meu endereço de entrega seja preenchido automaticamente a partir do meu CEP, para que eu possa concluir a compra com uma mão só.

O projeto épico se transforma em uma lista de tarefas compostas por partes como essa, cada uma delas testável e pequena o suficiente para ser gerenciada.

Celular

7. Modo offline

Como técnico de campo, quero que a folha de serviço de hoje seja carregada sem conexão, para que eu possa continuar trabalhando em porões e em áreas sem sinal.

Por que funciona: a função define o requisito. A equipe administrativa nem percebe o suporte offline; os técnicos de campo vivem nisso. Quando alguém pergunta “até que ponto é offline?” durante o refinamento, a função já respondeu — onde quer que o trabalho os leve.

8. Preferências de notificação

Como assinante que recebe três notificações por dia, quero escolher quais tipos de alertas enviam notificações, para não precisar mais silenciar o aplicativo inteiro.

Por que isso funciona: o benefício identifica o tipo de falha que a história evita. Os usuários não reclamam do volume das notificações; eles silenciam o aplicativo e vão embora sem dizer nada. Uma história que identifica o comportamento silencioso contra o qual está se defendendo é uma história sobre a qual a equipe pode discutir com franqueza.

APIs e trabalho técnico

9. Paginação

Como desenvolvedor de integração, quero respostas paginadas no endpoint /events, para que minha sincronização noturna não atinja o tempo limite em contas grandes.

Por que funciona: essa é a história de usuário técnica legítima — o desenvolvedor é um usuário real e externo, com seus próprios objetivos, e não a própria equipe se colocando na frase. Consumidores de API, autores de plug-ins e operadores de plantão, todos passam nesse teste.

10. Limitação de taxa

Como consumidor da API, quero receber uma resposta 429 com o cabeçalho Retry-After quando atingir o limite de taxa, para que meu cliente possa reduzir a frequência das chamadas em vez de interromper toda a tarefa.

Por que isso funciona: o objetivo é preciso o suficiente para ser, por si só, o primeiro critério de aceitação, e ainda se trata de um o quê, não de um como — nada aqui determina a implementação do limitador.

11. A refatoração disfarçada

Como desenvolvedor, quero refatorar o módulo de pagamentos para que o código fique mais limpo.

Por que isso não funciona: o papel é a equipe, o objetivo é uma atividade em vez de um resultado, e “mais limpo” não é algo que possa ser testado. Esse é o formato de história aplicado a um trabalho para o qual não foi concebido — um caso abordado em quando as histórias de usuário são a ferramenta errada.

A reescrita (não é uma história de usuário, propositalmente):

Reduzir o acoplamento do módulo de pagamentos aos provedores, de modo que um novo provedor de pagamentos possa ser adicionado sem alterar o núcleo do processo de checkout. Considerado concluído quando: a interface do provedor for extraída, os dois provedores existentes operarem por meio dela e o conjunto de testes de integração for aprovado sem alterações.

Um item técnico simples com um resultado específico é sempre melhor do que uma história cheia de fantasias.

É um bug ou uma funcionalidade?

12. O inseto que é uma história

Como cliente de um plano anual, gostaria que minha fatura refletisse o desconto que me foi oferecido, para que o departamento financeiro possa fazer a reconciliação sem precisar abrir um ticket de suporte.

Por que funciona: a causa é conhecida e a correção tem um escopo claro; portanto, isso se comporta como qualquer outra história — recebe critérios, um tamanho e um espaço no sprint. O trabalho de correção de bugs mantém a velocidade fiel à realidade sobre para onde a capacidade realmente é direcionada; o capítulo sobre pontos de história apresenta esse argumento de forma completa.

13. O bug que não é

Os clientes relatam, ocasionalmente, terem sido cobrados duas vezes. Não é possível reproduzir o problema de forma confiável.

Por que isso não é uma história: não há espaço para promessas. Uma frase do tipo “função-objetivo-benefício” (“Como cliente, quero não ser cobrado duas vezes…”) seria verdadeira, mas inútil, e qualquer estimativa serviria apenas para medir uma esperança. A atitude correta é um spike: investigar por dois dias, apresentar o que foi aprendido e, então, escrever a história real para a correção.

Ferramentas internas e relatórios

14. Ferramentas de suporte

Como agente de suporte no chat ao vivo, quero ver as últimas cinco tentativas de login do cliente, para que eu possa distinguir, à primeira vista, se se trata de uma senha esquecida ou de uma conta bloqueada.

Por que isso funciona: os usuários internos também são usuários. O benefício é medido em segundos por ticket, que é exatamente o tipo de resultado concreto que permite que essa tarefa concorra com o trabalho voltado para o cliente por uma vaga no sprint, em vez de ser automaticamente preterida.

15. Exportações

Como líder de equipe, quero exportar o relatório do sprint como CSV, para poder compartilhar os resultados com as partes interessadas que não têm contas.

Por que funciona: a oração com “para que” define discretamente o escopo do trabalho. Compartilhar fora da ferramenta é a tarefa, o que descarta soluções como painéis dentro do aplicativo e regras em um CSV simples e portátil. Uma boa oração de benefício faz o trabalho de design de graça.

16. A epopeia da visibilidade

Como gerente, quero um painel com tudo o que a equipe está fazendo, para ter uma visão geral.

Por que isso não funciona: “tudo” não é um escopo e “visibilidade” não é um resultado — nada aqui pode ser desenvolvido, testado ou dimensionado. Por trás de uma história como essa está uma questão real que ainda não foi levantada ao gerente.

A reescrita:

Como gerente de entrega responsável pela preparação da reunião de atualização de segunda-feira, quero ter a meta do sprint de cada equipe e seu status (vermelho/âmbar/verde) reunidos em uma única página, para que eu possa identificar os trabalhos bloqueados sem precisar entrar em contato com cada líder.

A mesma pessoa, o mesmo instinto, mas agora isso se encaixa em um sprint e o testador sabe quando está pronto.

O que os melhores têm em comum

Analise os doze que funcionam. Cada um deles nomeia uma pessoa específica o suficiente para ter uma opinião, define uma meta que essa pessoa reconheceria e traz um benefício que resiste a um “por quê?” sincero. Nenhum deles contém detalhes de implementação, e nenhum deles tenta ser completo — é para isso que servem os critérios de aceitação e a conversa de refinamento.

As quatro histórias ruins falham exatamente de duas maneiras, o que é encorajador: ou o benefício é circular (ninguém verificou o porquê) ou o escopo é um épico (ninguém verificou o tamanho). Ambas as falhas vêm à tona no momento em que sua equipe tenta estimar a história, e é por isso que as sessões de dimensionamento identificam histórias ruins mais rapidamente do que qualquer diretriz de redação — uma grande dispersão nos votos é a mensagem de erro desse formato. Escreva seu próximo lote seguindo o modelo, depois apresente-os à equipe usando o planning poker e veja quais deles convergem.

Perguntas frequentes

Qual é um exemplo de história de usuário?

“Como cliente recorrente, quero fazer login com meu e-mail e senha para poder ver meu histórico de pedidos.” Ela menciona uma pessoa específica, uma capacidade na perspectiva dessa pessoa e o motivo pelo qual vale a pena agendar o trabalho. Essa estrutura em três partes (função, objetivo, benefício) é o formato clássico de uma história de usuário.

Como se escreve uma boa história de usuário?

Indique uma função específica em vez de “um usuário”, defina o objetivo como algo que a pessoa faz, e não como algo que o sistema contém, e conclua a cláusula “para que” com um benefício que resista a um “por quê?” sincero. Em seguida, inclua os critérios de aceitação, pois a frase da história é apenas o ponto de partida para uma conversa, e não o requisito em si.

O trabalho técnico pode ser redigido na forma de uma história de usuário?

Às vezes. Se o “usuário” for real — um desenvolvedor de integração que utiliza sua API, um operador de plantão —, o formato funciona como está escrito. Se o único papel relevante for “a equipe”, deixe de lado a formalidade e escreva um item técnico simples, com um resultado específico e critérios de aceitação. A disciplina se mantém; a estrutura da frase não precisa ser a mesma.

Os bugs devem ser descritos como histórias de usuário?

Um bug com causa conhecida e uma solução clara pode ser incluído, e identificá-lo mantém a velocidade realista. Um bug que ninguém consegue reproduzir não pode ser incluído: não há como fazer uma promessa, então uma história seria apenas um palpite com uma cláusula de benefício. Primeiro, defina um prazo para a investigação e, depois, redija a história propriamente dita com base no que for descoberto.

Qual deve ser o nível de detalhamento de uma história de usuário?

Uma frase que resume a história, seguida de três a cinco critérios de aceitação. A frase dá início à conversa; os critérios registram o que foi decidido na conversa. Se a lista de critérios continuar crescendo além de cinco, a história já se tornou várias histórias, e os critérios indicam onde dividi-la.

Leituras relacionadas