Mise à jour janvier 2024
Dans cet article, je vous propose de voir l’essentiel à connaître sur les User Stories. Il a été rédigé en 2018 mais reste totalement d'actualité selon moi.
La nouveauté depuis 2028, c'est l'arrivée de l'IA et de LLM comme chatGPT qui peuvent vous accompagner dans la rédaction de vos User Stories.
Si vous souhaitez améliorer votre pratique tout en découvrant ce que l'on peut faire aujourd'hui avec les outils d'IA, je vous recommande la formation que j'ai mise en place avec Romain Couturier dédiée à cette thématique : “ChatGPT au service de vos User Stories“

Cet e-learning vous amènera à vous interroger sur la manière dont sont élaborées vos User Stories. Grâce à ChatGPT, vous bénéficierez d’un assistant de choix pour progresser en totale autonomie.

Ce sont encore les participants des précédentes sessions qui en parlent le mieux.  

Travaillant aux côtés de Product Owner, je joue souvent un rôle de rappel pour assurer un formalisme cohérent lors de la rédaction de ses User Stories. Dans ce cadre, j'ai repris les bonnes pratiques à garder en tête.

Tout d'abord, une User Story est une description simple et compréhensible d'une fonctionnalité. Mais ayez en tête qu’une User Story, comme son nom l'indique, est avant tout une histoire qui se raconte, créé la discussion et amène l’équipe à confirmer sa compréhension du besoin.

Une user story se compose :

• D’un titre explicite : 
• Par exemple : « Client détenteur d’une carte VISA règle sa commande ». 
• D’une phrase narrative structurée sous la forme « En tant que ... Je veux ... Afin de ... ». 
• Par exemple : « En tant que client détenteur d’une carte VISA, je veux saisir mes données bancaires afin de régler ma commande en ligne avec ma carte VISA ». 

Cette formulation permet au Product Owner d’apporter une vision orientée client et d’identifier précisément la fonctionnalité et le bénéfice attendu. 

• D’un ensemble d’exigences et de critères d’acceptation : 
• Par exemple : «Contrôle à effectuer sur le format de carte ». 

Une fois affinée, une User Story a une valeur business ou valeur métier. La valeur métier est décidée suite à une demande de priorisation du Product Owner à son client. Elle permet ainsi au client de s'engager sur une priorité, et au Product Owner d'indiquer la priorité métier à son équipe dans le backlog de produit.

La forme canonique d'une User Story

Une User Story présente une vision utilisateur autour de 3 axes : rôle, besoin et valeur métier

• Pour bien découper les types d’utilisateurs d'une user story, posez-vous la question : « De qui ai-je besoin d'obtenir le feedback sur la fonctionnalité ?". Vous saurez ainsi si la user story résout réellement son problème. Vous pouvez aussi vous poser la question suivante : "Si cette fonctionnalité n'est pas développée, qui va en pâtir ?".
• Affiner le "afin de" permet de clarifier la valeur apportée par la user story, et donc d'aider à la priorisation des user stories des prochains sprints. Si vous avez des difficultés à exprimer correctement l'objectif de la user story (le "afin de"), raisonnez en négatif : "que se passe-t-il si on ne le fait pas ? Quels sont les risques?"

Cette approche de rédaction est donc guidée par de bonnes questions à se poser. En voici 3 simples à se poser lors de la rédaction de vos User Stories :

• Qui a fait la demande ou qui bénéficie de la demande ? -> le rôle utilisateur
• Quelle est la demande ? -> le besoin
• Quelle valeur métier découle de la réalisation de ce besoin ? -> le bénéfice

Une “User Story” ça veut bien dire “histoire utilisateur”, pas “contrainte technique”

Si comme moi vous travaillez sur des systèmes qui proposent des API, il est facile de tomber dans des cas de rédaction du type "En tant que , je veux consommer les données X, Y et Z afin de vérifier la véracité de mes données avec celles du SI appelé...".

Si c'est le cas, reprenez les questions : 

• Qui a fait la demande ?
• Quelle est la demande ?
• Quelle valeur métier découle de la réalisation de ce besoin ?

... car vous voulez éviter ce type de User Stories bien trop génériques. 

Une bonne User Story respecte les caractéristiques réunies sous le sigle INVEST.

Si l'on suit ce framework INVEST, une bonne User Story est :

• Indépendante : une User Story est indépendante vis-à-vis des autres User Stories du backlog. Idéalement, elle se suffit à elle même pour éviter les dépendances avec d'autres User Stories. Car toute dépendance génère des problématiques de planification et de tests. 
• Négociable : une User Story est un support de discussion en vue d’une amélioration du besoin initial. Elle peut être modifiée, on parle d'affinage jusqu'à son intégration dans une itération ou Sprint. Généralement, on considère qu'elle est affinée lorsqu'elle répond aux critères de la "Définition of Ready" établie par l'équipe. 
• Valorisable : la réalisation d’une User Story doit rendre un service à l’utilisateur. Elle n'a de sens que si elle apporte une valeur métier. 
• Estimable : une User Story doit être bien définie pour être facilement estimable, quel que soit votre mode d'estimation. Si l'équipe n'est pas en capacité de l'estimer, c'est souvent que votre User Story manque de clarté.
• Small : une User Story doit être réalisable sur un sprint, soit suffisamment petite ou découpée de telle manière à pouvoir être déployée sur un seul sprint et minimiser les effets tunnels sur plusieurs sprints. Cherchez donc à découper vos User Stories le plus finement possible. Mieux vaut créer deux petites User Stories, qu'une grande.
• Testable : une User Story doit raconter une histoire dont les critères d'acceptabilité et les tests doivent découler de manière évidente pour faciliter sa validation. 

Les tests d'acceptation ou critères d'acceptabilités

Pour appuyer l'approche de TDD "Test Driven Developement" ou développement piloté par les tests, Gherkin est une approche d'écriture des tests d'acceptations.

Le principe de cette approche est de mettre les tests au cœur du projet. C'est une approche de test par l'usage.

Avant de se lancer dans les tests d'acceptation, petits rappels pour éviter des confusions entre les différents types de tests possibles :

Quels sont les différents types de tests : 

• Les tests unitaires (TU)

Il s'agit d'un code source qui permet de vérifier un mécanisme de l'application. Un test = Un cas

• Les tests d'intégration (TI)

Il s'agit de tests permettant d'assembler tous les modules indépendants de l'appli et de les tester.

• Les tests système (TS)

Ils regroupent les tests de performances, de compatibilités, de sécurité, de volume...

• Les tests d'acceptation (TA)

C'est un outil de communication fourni par le Product Owner qui permet de déterminer quand une User Story est terminée. C'est un test qui peut être écrit conjointement avec le Product Owner, l'expert métier, un ou des devs et le Scrum Master. Les test d'acceptation sont concentrés sur le QUOI plutôt que sur le COMMENT

Ils permettent de garantir la conformité entre la fonctionnalité livrée et les règles fonctionnelles définies dans la User Story. Ce qui revient à décrire des cas d'utilisation ou scénarios de tests de cette histoire démontrables lors des Review de fin de sprint ou démos auprès des utilisateurs par exemple.

Le langage Gherkin "GIVEN - WHEN - THEN" pour définir ses scénarios

Ce format provient du BDD (Behavior Driven Developement).

La syntaxe utilisée, appelée désormais langage Gherkin, est de plus en plus reconnue par des Fra- meworks (tels que jBehave ou Cucumber) permetant d’automatiser des tests fonctionnels.

L'approche Gherkin a pour objectif d'intégrer une formalisation du développement pour obtenir automatiquement des tests fonctionnels en écrivant des scénarios de tests compréhensibles par des individus non techniques. 

Cette approche sert deux objectifs : 

1. Documenter les fonctionnalités à développer 
2. Permettre l’automatisation des tests 

La définition d’un scénario de test en Gherkin se fait selon trois étapes clés : Given, When Then.

• Given liste les conditions initiales nécessaires au test (les données en entrée souvent)
• When décrit les actions à effectuer (ce qui doit être testé)
• Then décrit le résultat attendu en cas de bon fonctionnement du produit (les données que l'on veut récupérer en sortie souvent)

les utilisateurs suivants : Nom/Prénom, position/fonction ou une situation de départ donnée = UN CONTEXTE

j'ajoute/je supprime/je modifie cette donnée : l'utilisateur effectue une ou plusieurs ACTIONS

....(optionnel)

je dois obtenir ce résultat : on doit pouvoir constater telles conséquences ou situation d'arrivée

est utilisé de manière optionnelle pour ajouter des conditions au besoin

L'idéal est de s'appuyer sur un fichier d'injection d'un jeu de données qui sont nos valeurs de tests pour que ça reste fonctionnel et cohérent à l'échelle du projet entier.

Exemple Nominal

Fonctionnalité : Authentification

Scénario : Tentative d’authentification avec un compte valide

Étant donné que je dispose d’un compte utilisateur « marie »

Quand j’accède à la page d’authentification /auth.html

Et que je saisis mon identifiant « marie » dans le champ « Login »

Et que je saisie mon mot de passe dans le champ « Password »

Et que je clique sur le bouton « Connexion » du formulaire

Alors je suis authentifié sur le site

Et je suis redirigé vers la page « Mon compte » à l’URL /mon-compte.html

Autre exemple générique