Une user story est une description courte d’un besoin, exprimée du point de vue de la personne qui l’utilisera. Elle prend souvent la forme consacrée : « en tant que… je veux… afin de… ».
Cette formulation n’a rien d’anodin. Elle force à nommer un utilisateur réel, une action concrète et une finalité. Beaucoup de demandes ne survivent pas à l’exercice : lorsqu’on ne parvient à écrire ni le bénéficiaire ni le bénéfice, c’est généralement que le besoin n’a pas encore été compris.
La user story est une conversation, pas une spécification
L’intention d’origine, formulée par Ron Jeffries à travers la règle des trois C — carte, conversation, confirmation — est limpide : la story tient sur une carte parce qu’elle ne doit pas tout dire. Elle sert d’aide-mémoire pour une discussion entre l’équipe et le Product Owner.
C’est le contresens le plus répandu : rédiger des stories de deux pages, captures d’écran et règles de gestion exhaustives comprises, en espérant se dispenser de l’échange. On obtient une spécification classique déguisée, avec les mêmes malentendus qu’auparavant et un vocabulaire agile en plus.
Les critères d’acceptation, partie non négociable
Chaque story s’accompagne de critères d’acceptation qui définissent les conditions à remplir pour qu’elle soit considérée comme satisfaite. Ils répondent à la question « comment saurons-nous que c’est bon ? » et servent directement de base aux tests.
Un bon critère est vérifiable sans interprétation : « la recherche renvoie un résultat en moins d’une seconde » plutôt que « la recherche est rapide ». L’Agile Alliance maintient un glossaire de référence sur ces pratiques et leurs variantes.
Reste la question de la taille. Une story qui ne tient pas dans un sprint doit être découpée, mais le découpage par couche technique — une story pour la base de données, une autre pour l’interface — casse la logique même de l’exercice : aucune des deux ne livre de valeur à elle seule.