Tout savoir sur la rédaction de (bonnes) User Stories

Quel que soit ton rôle au sein d’un projet (Agile ou non), tu as sûrement déjà entendu parler des Users Stories (ou US). Elles ne sont ni plus ni moins que le cœur du projet. Assemblées, elles comportent la description fonctionnelle et parfois technique du besoin exprimé par le client (ou Métier/ Business). Elles comportent aussi la vision UX/ UI quand cela est nécessaire, le temps de développement associé, et l’ensemble des tests qui seront mis en œuvre. La mise en place d’une US peut parfois se révéler fastidieuse.

Beaucoup d’aspects théoriques expliquent comment une US doit être pensée lors de l’expression d’un besoin, comment elle doit être gérée et priorisée une fois celle-ci mise en backlog. Même si un PO tente de respecter et de mettre en œuvre ces préceptes, la pratique et le contexte propres à chaque client peuvent parfois aller à l’encontre de ces derniers.

Cet article a donc pour objectif de partager avec toi les bonnes pratiques de rédaction d’une US, et de confronter la théorie à la pratique.

A quoi sert une US ?

Le but premier d’une User Story est de décrire fonctionnellement et parfois techniquement un besoin. Tu pourras le lire ci-dessous, au moment de sa rédaction, ce besoin est déjà découpé finement, formant unitairement des US. Rassemblées, elles correspondent au besoin exprimé par le Métier et mûri par tous les acteurs du projet.

Exprimé brut au début du projet, le besoin se doit d’être affiné fonctionnellement et techniquement par l’ensemble des parties prenantes. En « sortie de chaîne », il peut se révéler parfois bien différent de celui attendu compte tenu des contraintes.

Il est donc nécessaire de procéder par découpage et en ressortir les grandes thématiques (appelées EPIC ou épopées) mais aussi de dégager ce que l’on appelle un MVP (Minimum Viable Product). Ce MVP représente la plus petite partie du projet qui peut être développée en un minimum de temps. Il permet d’apporter une vraie valeur client mais a également pour objectif d’amener rapidement un retour d’expérience afin d’ajuster, affiner ou refondre le besoin initial.

Ce travail est bien souvent réalisé lors d’un rituel Agile appelé « Story Mapping » qui réunit plusieurs personnes autour d’une table. Celui qui exprime le besoin, le PO, un représentant de l’équipe de développement, un UX / UI et le testeur.

Ainsi, cette vision 360° permet d’apporter toutes les connaissances nécessaires lors du découpage du besoin et d’anticiper au maximum les éventuels points de blocage ou non faisabilité.
En sortie d’atelier, le PO doit avoir identifié son MVP et ses EPICs, qui lui permettront de pouvoir, ensuite, imaginer ses US et les rédiger.

Comment la rédiger : de la théorie…

Tous les PO ont une base de travail commune. Ils commencent la rédaction d’une user story via la méthode INVEST ; puis suivent le cycle de vie de celle-ci au sein de JIRA (outil de gestion majoritairement utilisé).

La méthode INVEST est l’abréviation de plusieurs règles théoriques qui te permettront d’identifier les fondements d’une user story. Cette méthode qui suit, respecte les points suivants :

I.N.V.E.S.T : Méthode de rédaction des US

… A la pratique

Lors de la rédaction de nos premières User Stories, nous les parcourons une à une pour voir si elles répondent aux principes INVEST. Au fur et à mesure, c’est devenu un automatisme. Nous gardons en tête les fondements lors de la création des US sans pour autant nous interroger sur le respect ou non de la théorie. Ainsi, ci-dessous tu trouveras quelques exemples mis en œuvre lors de nos missions respectives :

“Le fait de vouloir découper finement la fonctionnalité entraîne une certaine dépendance entre les US. Parfois, je suis amenée à compléter une user story par une technical story (US technique). L’US devient donc dépendante de la technical story. “ – Namel

“L’estimation des users stories n’est pas forcément réalisée en fonction des clients. Il arrive encore que les US soient estimées en Jours Hommes et non en points de complexité.” – Sophia

“Dans la majorité des cas, les US sont testables en fin de sprint. Cependant si les US sont dépendantes entre elles, il se peut qu’elles soient non testables à la fin des développements de chacune.”– Namel

Un conseil pour toi lecteur : s’il n’y a pas d’ordonnancement précis pour traiter les points INVEST, il est intéressant en revanche de commencer par le point VALEUR afin d’identifier les US ayant le plus de valeur utilisateur. Il se peut qu’une US soit abandonnée après l’estimation de sa valeur.

Durant le projet, le cycle de vie d’une US peut se suivre sur un board KANBAN avec les étapes ci-dessous. Il faut aussi prendre en compte que cette façon d’ordonner les colonnes et les intitulés des statuts proposés ci-dessous peuvent dépendre de la façon dont est organisée ton équipe, du niveau de maturité agile et de ton projet :

Une fois l’US validée par l’équipe QA / Recette, elle peut donc être mise en production.

Namel :

“En tant que Product Owner, on est responsable du bon suivi du board. Chez Crédit du Nord, sur le projet de refonte du portail collaborateur, pour faciliter les échanges avec les 4 développeurs et mon PPO, nous avons mis en place un board dédié à l’équipe PO qui reprend les étapes suivantes : New, conception, ready to dev (RTD). Une fois l’US à l’étape RTD, elle arrive automatiquement dans le backlog d’un deuxième board dédié aux développeurs. Au poker planning de chaque sprint, on embarque les US à réaliser, elles arrivent donc à l’étape TO DO. Leur état change en fonction de l’avancement du sprint.”

Sophia :

“Ma pratique pour le projet de lancement de l’espace client de Gecina est complètement différente de l’expérience de Namel chez Crédit du Nord. En effet, nous n’avions qu’un seul board constitué des étapes ci-dessus, mais avec des termes différents (par exemple au lieu de “In progress”, l’étape se nomme “En dev”) et les échanges avec les 4 développeurs du projet n’était pas pour autant perturbé. Les termes des étapes peuvent varier selon les habitudes de l’entreprise, l’objectif est d’arriver au même résultat.”

Comme indiqué ci-dessus, la rédaction des US se fait en phase de conception.

En complément de la méthode INVEST, tu peux utiliser le template unique qui te permettra de structurer l’US.
Ce dernier est composé d’un intitulé (En tant que (utilisateur final), je souhaite (l’action) afin de (besoin)) et de critères d’acceptation (Étant donné que (situation de l’utilisateur) Et (complément de situation) Quand (action réalisée) Alors (résultat obtenu)).

Chez nos clients respectifs (Accor pour Sophia, Axens pour Namel), nous utilisons le template décrit ci-dessus lors de la rédaction des US. En effet, le fait d’avoir un template nous oblige à respecter la trame et d’avoir des US homogènes. Cette uniformisation permet donc de faciliter la compréhension de l’équipe de DEV.
En revanche, pour le client Gecina pour Sophia et PSA pour Namel, cet aspect était relativement respecté au démarrage des sprints. Nous avons constaté qu’en fonction du niveau de maturité de la dev team, nous n’étions plus contraintes d’utiliser la formulation.

5 bonnes pratiques pour finir

Pour finir cette lecture, on te propose une liste de best practices qui pourra te servir dans ton quotidien.

1. L’intitulé de ton US peut être différent de la norme

Chez Foncia, dans le cadre de la refonte de l’espace client et chez PSA, pour la mise en place d’un outil de traitement des incidents d’usine, l’intitulé des US était différent de la norme théorique. Nous préférions les intituler par fonctionnalité ou besoin utilisateur. Malgré le respect de la structure de l’US lorsqu’on travaille avec la Dev Team en sprint planning ou backlog grooming sur Jira on se rend compte que toutes les US portent le même nom. On est donc contraint de rentrer dans le détail de chaque US.
Par exemple, nous mettons en intitulé “Page d’identification / authentification” à la place de : “En tant que client bancaire, je souhaite m’authentifier sur l’espace client afin de consulter mes comptes”.

2. On te conseille fortement d’accompagner ton US d’un visuel

“Le visuel est une aide supplémentaire pour la dev team. Elle s’appuiera dessus pour valider un comportement souhaité. Par exemple, chez Accor Hotels, pour développer les évolutions du site e-commerce liées aux nouvelles offres commerciales : l’US n’était pas considérée comme étant prête à être développée tant qu’elle n’était pas accompagnée d’une maquette”– Sophia

3. Fais attention au nombre d’US que tu dois embarquer au démarrage d’un sprint

“La vélocité se définit au cours des sprints. Je te conseille au démarrage de ne pas embarquer énormément d’US afin d’éviter un reliquat d’US non terminées. En effet, lors de ma mission chez Crédit du Nord pour le projet de Biométrie vocale, nous avons constaté qu’un reliquat d’US peut avoir un effet négatif sur la motivation de l’équipe et engendrer une déception. Il est donc conseillé d’embarquer une quantité raisonnable de points de complexité et d’en rajouter pendant le sprint en cours en fonction de l’avancement de la DEV Team. Cela nécessite que les US de la backlog soient priorisées et en statut Ready to dev” – Namel

4. L’importance d’un bon découpage d’US

“Lors des instances d’estimation (sizing), il est important de bien découper les US.
Une astuce ? Tu peux découper une fonctionnalité de taille importante en plusieurs US. Même si elles deviennent dépendantes l’une de l’autre. Par exemple, la règle d’or était de n’avoir aucune US à plus de 8 points de complexité. Si une US était estimée à plus de 8, nous procédions au découpage de celle-ci en plusieurs US” – Namel

5. N’oublie pas de faire valider le besoin avec tes Business Owners

“N’hésite pas à demander précision ou à remettre en question le besoin des utilisateurs / Business Owners. Cela te permettra de répondre au mieux à leurs attentes. Voici un exemple : Dans le but d’optimiser l’application mobile du Groupe Barrière (hôtels), je reformulais leur besoin avec mes propres mots. Me permettant ainsi d’être certaine qu’on soit sur la même longueur d’onde, à la fin de chaque atelier.” – Sophia

Il y a deux principales compétences dont tu dois faire preuve pour la rédaction d’une US : l’adaptabilité et la communication avec l’équipe de développement. Effectivement, chez certains de nos clients, nous devions respecter la structure d’une US, alors que chez d’autres clients, les critères d’acceptation étaient plutôt remplacés par des règles de gestion plus complexes. Ensuite, le Business Owner validait ces dernières détaillées dans un document de spécifications fonctionnelles. Ce document peut-être utilisé en complément des US.

Finalement, tu l’auras bien compris, la façon d’aborder une US dépend totalement de l’environnement de travail du client et de la maturité Agile de l’équipe projet. L’avantage d’effectuer diverses missions est d’enrichir nos méthodes de travail et d’apprendre des contextes clients. Cet enrichissement nous aide à consolider et à améliorer au fil du temps notre capacité à rédiger une “Bonne User Story” et gagner en expertise dans notre fonction de Product Owner.

---

Qui a contribué à cet article ?

Consultantes chez World Of Digits depuis environ 3 ans, Sophia et Namel sont également contributrices pour la Tribu PO. Cette tribu a pour vocation de partager et apprendre des autres à travers différents workshops et articles qu’elles produisent.

“J’ai commencé dans l’univers du digital en tant que Chef de projet e-commerce pour le pôle hôtellerie du Groupe Barrière pendant 2 ans. Après une année passée dans l’entrepreneuriat, j’ai intégré WOD en tant que consultante Chef de projet/ Product Owner. J’ai accompagné divers clients tels que Foncia, Accor Hotels ou Gecina. Je suis actuellement Business Analyst Digital pour Axa sur différents projets permettant d’optimiser les espaces client.”

“J’ai d’abord été Cheffe de projet pendant 2 chez Crédit Agricole avant de découvrir le milieu du consulting. J’ai ensuite pu effectuer 5 missions en tant que Business Analyst. Lorsque j’ai rejoint WOD, j’ai démarré ma mission au Crédit du Nord en tant que Proxy Product Owner. Au fil du temps, je suis devenue Product Owner sur le projet de Biométrie Vocale. J’accompagne maintenant mon client en tant que Product Owner sur quatre projets différents. Mon évolution au sein de ma mission témoigne de la relation de confiance que nous entretenons avec notre client. “

Ecrit par Namel & Sophia