« En tant que client, je souhaite enregistrer mon mode de paiement pour passer en caisse plus rapidement la prochaine fois. » Voilà une user story. C'est une phrase, pas un cahier des charges. Les équipes de développement agile les notent sur des fiches ou des post-it. Ce format oblige le rédacteur à préciser un rôle, un objectif et une raison. Il permet de se concentrer sur l'utilisateur final, et non sur le schéma de la base de données.

Les user stories ont été popularisées par Kent Beck et Ron Jeffries à la fin des années 1990. Elles sont volontairement incomplètes. Elles constituent une promesse de discussion : développeurs, designers et chefs de produit en discutent les détails. Les critères d’acceptation sont ajoutés ultérieurement. Une user story trop longue est appelée une épopée. Une user story trop vague est un bug en puissance.

Les trois C

• Card: l'histoire écrite, suffisamment courte pour tenir sur une feuille de papier.
• Conversation: la discussion qui comble les lacunes.
• Confirmation: les tests qui prouvent que cela fonctionne.

Les bonnes histoires sont indépendantes, négociables, précieuses, estimables, concises et testables. L'acronyme est INVEST. Ce n'est pas une religion. Certaines équipes conçoivent leurs histoires comme des scénarios de travail : « Quand je suis en retard, je veux payer en un seul clic pour ne pas rater mon train. » Même idée, formulation différente.