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

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 um deles vem acompanhado 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 entender o que é uma história de usuário. Resumidamente, todas as histórias aqui seguem o formato “Como [função], eu quero [objetivo], para que [benefício]”, e qualquer história bem elaborada poderia passar diretamente para o refinamento e para 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: o papel é específico. “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 campos estão preenchidos, mas não há nenhuma informação nova. O papel é “ninguém em particular”, e o benefício apenas reafirma o objetivo; portanto, a cláusula “para que” poderia ser excluída 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á retornando no meio do sprint, quero acessar o quadro que vi pela última vez depois de fazer login, para não precisar navegar até lá todas as manhãs.

Aí está 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 quando eu voltar à noite, para que eu não precise procurar tudo de novo.

Por que funciona: o papel transmite um cenário. “Navegar 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 que mude de ideia.

Por que funciona: apresenta uma proposta de produto (as contas são opcionais) e expõe 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 de um trimestre de trabalho condensado em uma frase, o que a torna um épico, não uma história.

A reescrita (um trecho 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á deu a resposta: 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 de 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 isso 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, desejo 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 pode ser testado. Trata-se do formato de história aplicado a um trabalho para o qual não foi projetado, um caso abordado no artigo “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 finalização da compra. 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 bug que é uma história

Como cliente de um plano anual, quero que minha fatura mostre o desconto que me foi oferecido, para que o departamento financeiro possa fazer a conciliaçã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 alinhada com a real alocação da capacidade; o capítulo sobre pontos de história apresenta esse argumento de forma completa.

13. O bug que não é

Os clientes relatam, de forma esporádica, terem sido cobrados duas vezes. Não é possível reproduzir o problema de maneira 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. O caminho certo é um “spike” com prazo definido: 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 funciona: os usuários internos também são usuários. O benefício é medido em segundos por ticket, o que é exatamente o tipo de impacto 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 possuem 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 arquivos CSV simples e portáteis. 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 que mostre tudo o que a equipe está fazendo, para que eu tenha visibilidade.

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, há uma pergunta real que ainda não foi feita ao gerente.

A reescrita:

Como gerente de entrega responsável pela preparação da reunião de atualização de segunda-feira, quero ter em uma única página a meta de sprint de cada equipe e seu status (vermelho/âmbar/verde), para que eu possa identificar o trabalho bloqueado 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 novamente os doze que funcionam. Cada um deles cita uma pessoa específica o suficiente para ter uma opinião, define uma meta que essa pessoa reconheceria e apresenta um benefício que resiste a um “por quê?” sincero. Nenhum deles contém detalhes de implementação, e nenhum deles tenta ser exaustivo. É 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.” Isso identifica 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 conforme descrito. Se o único papel relevante for “a equipe”, deixe de lado a formalidade e redija um item técnico simples, com um resultado definido 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 redigidos como histórias de usuário?

Um bug com causa conhecida e uma solução clara pode ser, e apontá-lo mantém a velocidade realista. Um bug que ninguém consegue reproduzir não pode: não há como fazer uma promessa, então uma história seria apenas um palpite com uma cláusula de benefício. Defina primeiro um prazo para a investigação e, em seguida, escreva a história real 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 refletem 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.

Leitura relacionada

• Estimativa ágil: o guia completo. Aqui você encontra tudo o que precisa saber.
• O que é uma história de usuário? O formato, os três Cs e a lista de verificação INVEST por trás de cada exemplo acima.
• Modelo de história de usuário e critérios de aceitação. Um modelo pronto para copiar e colar e um exemplo prático, incluindo a estimativa.
• Divisão de histórias de usuário. O que fazer com os épicos que estão nos exemplos 6 e 16.
• Exemplos de estimativa ágil. A série complementar: como realmente soa a avaliação do tamanho dessas histórias na sala.