"Como cliente, quero guardar o meu método de pagamento para finalizar a compra mais rapidamente da próxima vez." Esta é uma história de utilizador. É uma frase, não uma especificação. As equipas de desenvolvimento ágil de software escrevem-nas em fichas ou post-its. O formato obriga o autor a nomear uma função, um objetivo e uma justificação. Isto mantém o foco na pessoa que irá realmente utilizar o recurso, e não no esquema da base de dados.

As histórias de utilizador foram popularizadas por Kent Beck e Ron Jeffries no final da década de 1990. São propositadamente incompletas. O cartão é uma promessa de conversa. Os programadores, designers e gestores de produto discutem os detalhes. Os critérios de aceitação são adicionados posteriormente. Uma história muito grande é chamada de épica. Uma história muito vaga é um bug prestes a acontecer.

Três Cs

• Card: a história escrita, curta o suficiente para caber no papel.
• Conversation: a discussão que preenche as lacunas.
• Confirmação: os testes que comprovam que funciona.

As boas histórias são independentes, negociáveis, valiosas, estimáveis, pequenas e testáveis. O acrónimo é INVEST. Não é uma religião. Algumas equipas escrevem histórias como se fossem histórias de trabalho: "Quando estou atrasado, quero pagar com um único toque para não perder o comboio". Mesma ideia, perspectiva diferente.