Histórias de Usuário: 8 dicas para escrever boas user stories

De onde vieram as histórias de usuário?

Histórias de usuário surgiram no XP (Extreme Programming), no final da década de 80, com o objetivo de representar o desejo do usuário por alguma funcionalidade de forma fácil de priorizar. Assim como outras técnicas do XP – TDD e Pair Programming – as user stories se difundiram e hoje são usadas em praticamente qualquer Método Ágil, independente de ser Kanban, Scrum, XP ou Lean Startup.

8 dicas para escrever boas histórias de usuário

1. Foco no cliente ou usuário final

O foco de uma história de usuário deve estar sempre no que o cliente ou usuário final realmente deseja – não no que você acredita que ele deseja. Sem esse foco, as chances são de escrever user stories sem valor real para o produto.

2. Utilize personas

Quando você não conhece bem o seu cliente ou usuário final, criar personas – personagens com as características do seu usuário real – ajuda a levantar os desejos por trás das histórias. É comum um produto ter mais de uma persona; combinar personas com story mapping facilita ainda mais esse trabalho.

3. Histórias de usuário são informais

User stories não substituem a documentação do projeto. Elas servem apenas para representar os desejos de clientes e usuários – mantenha-as como conversas informais, que vão mudar algumas vezes ao longo do caminho.

4. Devem representar valor de negócio

Mesmo sendo informal, toda história de usuário precisa ter um motivo claro para existir. É comum encontrar user stories sem o “porquê” preenchido – deixe o valor de negócio explícito.

5. Siga o modelo INVEST

Segundo Mike Cohn, uma user story só é válida se seguir o modelo INVEST:

Letra	Critério	O que significa
I	Independente	Não depende de outras histórias para fazer sentido.
N	Negociável	É um ponto de partida, não um contrato fechado – pode ser renegociada.
V	Valiosa	Representa valor de negócio real; sem isso, não faz sentido existir.
E	Estimável	O time precisa ser capaz de estimá-la.
S	Pequena (Small)	Reduz incertezas e dificuldades na estimativa.
T	Testável	É possível validar se ela atinge os critérios de aceitação.

6. Comece pelas grandes e termine nas pequenas

Comece identificando os Épicos – histórias grandes demais para serem implementadas de uma vez. Por exemplo: “Como usuário, gostaria de pagar minha compra para receber os produtos” é um Épico, porque dentro dele existem várias decisões (forma de pagamento, parcelamento, etc.) que geram histórias menores. Partir dos épicos é uma boa forma de descobrir as histórias de usuário menores.

7. Mantenha as histórias de usuário visíveis

User stories existem para promover colaboração e conversa – não as deixe escondidas numa planilha. Uma técnica útil é o Story Board, um quadro com 3 colunas: Ideias (novas ideias do PO), Validação de Valor (histórias em validação de valor de negócio) e Priorizadas para o Product Backlog (histórias com valor de negócio já identificado).

8. Não confie apenas nas histórias

Como são informais, user stories não devem ser a única fonte de informação. Complemente com o que for necessário – um diagrama de sequência, um template de jornada do usuário ou um protótipo – sempre que isso agregar valor real para o time de desenvolvimento.

Erros comuns ao escrever histórias de usuário

• Escrever a história com base no que você acha que o cliente quer, em vez de validar com o cliente real.
• Tratar a história de usuário como documentação completa, em vez de um ponto de partida para conversa.
• Deixar o “porquê” (valor de negócio) vazio na história.
• Escrever histórias grandes demais (épicos) sem quebrá-las em histórias menores e testáveis.
• Manter as histórias escondidas numa ferramenta sem visibilidade para o time.

Perguntas frequentes sobre histórias de usuário

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

É uma representação informal do desejo de um usuário por uma funcionalidade, usada para levantar requisitos ágeis de forma fácil de priorizar – não um documento formal de requisitos.

O que é o modelo INVEST?

Um checklist de qualidade para histórias de usuário: Independente, Negociável, Valiosa, Estimável, Pequena (Small) e Testável.

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

Um épico é uma história grande demais para ser implementada de uma vez – ele precisa ser quebrado em histórias de usuário menores, estimáveis e testáveis.

Histórias de usuário substituem a documentação do projeto?

Não. Elas são informais por natureza; quando necessário, devem ser complementadas com diagramas, protótipos ou outros artefatos.