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

Dezesseis exemplos de histórias de usuário comentadas nas áreas de autenticação, comércio eletrônico, dispositivos móveis, APIs e bugs, com as versões incorretas apresentadas ao lado de suas reformulações, para que a diferença fique clara.

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 são apresentadas ao lado de suas versões revisadas, pois a maneira mais rápida de aprender o formato é observar quando ele dá errado.

Se o formato em si for novidade 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 qualquer história bem elaborada pode passar diretamente 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: 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 utilizar. “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 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á 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 o intervalo do 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: a função 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. Uma função bem escolhida transmite o contexto em uma única frase.

5. Finalização da compra como visitante

Como sou um comprador de primeira viagem, 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 direta: a hesitação impede a primeira compra. 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 pilha de 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 determina a exigência. A equipe administrativa nem percebe o suporte off-line; os técnicos de campo vivem nisso. Quando alguém pergunta “o que significa exatamente ‘off-line’?” durante o aperfeiçoamento, 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 modo 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 inserindo na frase. Usuários da 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, e não 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, de propósito):

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 bug que virou uma história

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

Por que isso funciona: a causa é conhecida e a correção tem um escopo claro; portanto, isso funciona 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, de forma esporádica, que foram 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: 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, 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 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 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 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 apresentam falhas 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 usando o modelo, depois apresente-os à equipe com 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 serve apenas para iniciar uma conversa, e não constitui 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 a única função genuína for “a equipe”, deixe de lado a formalidade e redija 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 redigidos como histórias de usuário?

Um bug com causa conhecida e uma solução clara pode ser incluído, e apontá-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. 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