L'art de rédiger des User Stories

L’art de rédiger des User Stories

Nous l’avons vu dans un article précédent, si les cas d’utilisation (Use Cases) ont pour but de décrire comment un acteur interagit avec le système, l’objectif principal des User Stories est de présenter la finalité, la valeur ajoutée, d’une fonctionnalité du point de vue de l’utilisateur. On ne s’attarde pas ici sur le « comment », mais plutôt sur les « pourquoi » et « pour qui ».

Prise de hauteur et raffinement

L’expression des besoins vise généralement à apporter une plus-value au niveau du business d’une entreprise. Le niveau de langage ne doit pas être technique, mais compréhensible par toutes les parties prenantes (managers, gestionnaires de projets, développeurs, clients ou fournisseurs). Il peut s’avérer utile d’utiliser des synonymes ou de rédiger des phrases plusieurs fois, mais de manière différente. La reformulation est un outil appréciable pour permettre à chacun de comprendre et valider ce qui est écrit. Lors des ateliers d’élicitation, dont le but est de capter les besoins et de les challenger pour évaluer leur pertinence et leur utilité, on part d’une big picture que l’on formalise sous forme d’Epic.

Une Epic est un besoin ou une idée majeure, trop grande ou trop complexe pour être développée directement dans un seul sprint.

ChatGPT (avril 2025)

Sprint, pas vraiment une course Dans un contexte Agile, plus particulièrement selon la méthodologie Scrum, le mot sprint fait référence à la période, délimitée dans le temps (généralement 2 ou 4 semaines), pendant laquelle les fonctionnalités sont implémentées par les développeurs.

Epics, Features et User Stories

Les descriptions fonctionnelles sont découpées, au moment de l’analyse fonctionnelle, selon la structure Epics > Features > User Stories.

Une Feature est une fonctionnalité concrète qui répond à un besoin utilisateur. Elle est plus petite qu'une Epic, mais parfois encore trop grosse pour être directement développée dans un sprint.

Vocabulaire En fonction des interlocuteurs ou des outils utilisés (Jira, StoriesOnBoard...), le vocabulaire peut varier. Parfois, le niveau Feature est laissé de côté ou on parle d'Initiative au niveau le plus élevé de formalisation. Peu importe. Ce qui compte, c'est de partir d'un besoin décrit à un niveau global pour arriver à un niveau de détail suffisamment petit pour être développé.

ChatGPT (avril 2025)

Une User Story est une explication générale et informelle d'une fonctionnalité logicielle écrite du point de vue de l'utilisateur final. Son objectif est d'expliquer comment une fonctionnalité logicielle apportera de la valeur au client.

Traduit de https://www.atlassian.com/agile/project-management/user-stories (janvier 2025)

En tant que… Je souhaite… Afin de…

Pour reprendre notre étude de cas, pour décrire le fait qu’il existe différentes manières de parcourir le catalogue des photos, notamment via des thèmes associés, on pourrait rédiger la User Story “Visiteur” de la manière suivante.

En tant que visiteur
Je souhaite consulter le catalogue par thème
Afin de voir des photos thématiques

La formulation “En tant que/Je souhaite/Afin de” est typique de la notion de User Story.

“En tant que…” identifie l’acteur de l’action (le persona).
“Je souhaite…” décrit la fonctionnalité désirée.
“Afin de…” précise le but, l’objectif qui crée de la valeur du point de vue de l’utilisateur final.

Pour qui ? Il est important de bien identifier les acteurs (personas) impliqués dans le projet. Il peut être intéressant de préciser le type d’acteur. Par exemple : utilisateur, utilisateur identifié, utilisateur B2B... Il se peut que des acteurs hors périmètre (out of scope) soient identifiés dans des stories qui ne seront pas implémentées, mais qui servent à comprendre les interactions d’un point de vue business. Ex. : comptable, fournisseur, administration... Dans certains cas, un persona peut être le nom d’une personne spécifique (ex. : Marc, le responsable des achats...) qui incarne le rôle et ses attributions. La liste des acteurs doit être établie d’un point de vue fonctionnel. Les actions et flux sont formalisés dans un schéma de cas d’utilisation (use cases).

Granularité

Il est primordial de découper les User Stories en fonctionnalités de taille acceptable pour être réalisée en un seul sprint.

Si le scope est trop petit (granularité trop fine), la User Story va s’apparenter à une sous-tâche et ne représente pas une valeur ajoutée concrète et compréhensible pour l’utilisateur.

Ne pas confondre moyen et objectif

Il est important de définir l’objectif de la User Story (« Afin de… »), du point de vue de l’utilisateur, pour que le client puisse comprendre et valider la fonctionnalité. Cette définition de l’objectif doit être différente de la description de la fonctionnalité (« Je souhaite… »). Par exemple, le but final d’une fonctionnalité n’est pas d’afficher un graphique, mais de pouvoir l’interpréter et évaluer les données. Le graphique est un moyen (« Je souhaite… ») d’appréhender une situation (« Afin de… »).

Il se peut qu’à ce stade encore, on réalise qu’une fonctionnalité n’est pas vraiment essentielle ou utile d’un point de vue métier. L’analyse fonctionnelle et ses formalismes proposent un support de documentation et de communication entre les différents intervenants.

Critères d’acceptation

Sans critères d’acceptation, une User Story n’est pas complète. Ce sont eux qui vont permettre aux développeurs, au responsable de la qualité et au client de valider la fonctionnalité.

Un scénario présente le contexte de manière succincte.

Scénario : sur la page d’accueil est présenté un nuage de tags, permettant une navigation par thème des photos.

Une description plus verbeuse ajoute du contexte.

Description. À chaque photo sont associés des tags, permettant un parcours transversal du catalogue par thème (ex. : N&B, ville, personne…), plutôt que par collection. Une collection regroupe des photos de manière logique, mais les thèmes associés à ces photos peuvent varier.

La formalisation “Étant donné que/Quand/Alors” est utilisée.

Étant donné que l’utilisateur entre l’adresse du site
Quand il accède à la page d’accueil
Alors un nuage de tags lui est présenté

“Étant donné que…” précise le point de départ ; dans notre cas, on part du principe que l’utilisateur connaît l’adresse du site.
“Quand…” indique le déclencheur ; on peut rester très haut niveau à ce stade (objectif fonctionnel utilisateur).
“Alors…” définit ce qui se passe, l’action à réaliser.

Une liste des étapes successives peut être détaillée.

L’utilisateur entre l’URL photos.souvenirdunsoir.eu dans la barre d’adresses de son navigateur.
La page d’accueil du site s’affiche.
Un nuage avec tous les tags utilisés sur les photos est affiché et cliquable.

C’est ce qu’on appelle les critères d’acceptation (acceptance criteria) permettant de tester la fonctionnalité une fois implémentée, afin de s’assurer qu’elle correspond bien au besoin identifié au départ.

Remarque Le périmètre de cette User Story est volontairement grossier, dans un but didactique. Bien entendu, certains critères d'acceptation peuvent être plus précis, mais jamais trop techniques, pour éviter un jargon incompréhensible par le client.

Raffinement des critères d’acceptation

Si lors de la discussion avec le client, les critères d’acceptation sont exprimés en des termes très généraux, afin d’être compréhensibles pour lui, des détails peuvent être apportés, à l’issue d’une analyse technique, dans un document annexe, lors du passage au développement proprement dit. L’idée étant d’aller jusqu’à un niveau permettant de mettre en place des tests automatisés, processus indispensable dans un processus CI/CD (Continuous Integration/Continuous Deployment).

Si le concept de User Story est assez simple, toute la difficulté réside dans leur rédaction et leur granularité, afin de pouvoir représenter un bloc suffisant important, mais pas trop, pour être pris en charge par les développeurs.

Keep it simple Nous nous limiterons ici à une présentation simplifiée de la rédaction des User stories, sans aborder des concepts essentiels comme le versioning, la priorisation ou le statut de validation et d'avancement.

Dans un prochain article, nous présenterons le stack d’outils utilisés pour notre case study, essentiellement basé sur les produits Apple (Freeform, Notes et Rappels).