Quel que soit votre rôle dans l’équipe de développement d’un produit digital, même (et surtout peut être) en tant que client ou donneur d’ordre, vous avez été, ou serez confrontés à ce terme : User Story ou Récit utilisateur en bon français !

Qu’est-ce qu’une User Story ?

Issue de la méthodologie de gestion de projet agile Scrum, une User Story est une phrase qui permet d’exprimer de façon claire et très simple une fonctionnalité découlant d’un besoin utilisateur.  Véritable garante de la création de valeur d’une fonctionnalité pour l’utilisateur, elle a plusieurs avantages :

• Elle assure un langage commun entre toutes les parties, de l’équipe de développement au client. La responsabilité de sa rédaction incombe le plus souvent au Product Owner (PO), représentant du client au sein d’une équipe Scrum.
• Elle permet un gain de temps considérable pour les équipes techniques en leur fournissant des indications claires et précises sur les fonctionnalités à développer.
• Elles offrent la garantie que la fonctionnalité à développer répondra de la manière la plus efficace possible à l’expression d’un besoin client.

Quelle forme doit prendre une User Story ?

Si chaque agence, chaque PO peut avoir son propre framework pour la rédaction de ses User Stories, certains critères essentiels concernant la rédaction formelle doivent être respectés. Une User Story doit prendre en compte plusieurs dimensions :

• L’utilisateur
• La fonctionnalité
• Le besoin (pourquoi cette fonctionnalité est-elle nécessaire ?)

Une convention de rédaction a donc été définie et est aujourd’hui universellement respectée. Une User Story respecte toujours la forme suivante :

En tant que (As) …. Je veux (I want to) …. Afin de (So that)…

En tant que représente non seulement l’utilisateur mais plus largement toute partie au projet ou toute entité en lien direct avec le produit.

Je veux est suivi par une action qui va représenter la fonctionnalité à développer

Afin de sera suivi par l’objectif de cette action, la finalité de la fonctionnalité à développer.

Par exemple : En tant qu’utilisateur, je veux pouvoir créer un profil simplement depuis un smartphone afin de pouvoir utiliser le service aussi en déplacement.

DoR, DoD et Critères d’acceptations

DoD ou Definition of Done

Ecrire une User Story ne suffit pas. Encore faut-il qu’elle puisse être validée. Son rôle est de permettre le développement d’une fonctionnalité. Une User Story n’a pas vocation à exister pour exister. Elle est un outil au service d’une équipe de développement. Et un outil n’est utile que si l’on s’en sert. Il faudra donc, lors de la définition de vos User Stories, vous assurer de définir des critères d’acceptation. On parle aussi de Definition Of Done (DoD). Il s’agit ici de se mettre d’accord sur ce qui va permettre de valider une fonctionnalité. De stopper son développement et de la considérer comme terminée.

Lorsqu’une fonctionnalité sera développée, elle passera les tests d’acceptation, basés sur les critères d’acceptation de la User Story. Une fois ces tests passés, si les critères d’acceptation définis en amont sont respectés, la fonctionnalité sera considérée valide.

Se mettre d’accord en amont sur la DoD est une condition essentielle à l’efficacité d’une équipe. Cette notion ne s’applique pas seulement à la rédaction d’une User Story.

DoR ou Definition of Ready

De la même manière, il faut, lors de la rédaction de vos User Stories, penser à la DoR (Definition of Ready). En effet, dans un contexte agile, chaque User Story est indépendante des autres. Par conséquent, elles peuvent la majorité du temps être développées de manière autonome. Cela serait vrai dans un monde parfait dans lequel les dépendances entre les fonctionnalités seraient totalement inexistantes. Même si l’agilité tend à limiter drastiquement ces dépendances, tout projet est soumis à des imprévus, des aléas et souvent, ils sont liés à des dépendances non identifiées en amont. Pour éviter au maximum les risques liés aux dépendances entre les fonctionnalités, il convient de définir précisément les critères qui permettront de considérer une User Story comme étant prête à être développée. C’est ce que l’on appelle la DoR. Definition of Ready.

La Grille Invest

Une fois votre User Story rédigée, il existe un instrument redoutable pour évaluer sa qualité. Un acronyme qui vous fera parfois passer des nuits blanches mais qui garantit que la User Story que vous allez présenter à votre équipe est quasiment parfaite. Cet acronyme se nomme INVEST et est constitué de 6 adjectifs (en anglais) :

• Independant : Votre User Story doit se suffire à elle-même. Elle doit, dans la mesure du possible pouvoir être entièrement développée de manière indépendante.
• Negotiable: Une User Story doit pouvoir être discutée, remise en cause, challengée jusqu’au moment où elle est intégrée dans un sprint de développement.
• Valuable: Elle doit apporter de la valeur à l’utilisateur.
• Estimable: la complexité d’une User Story doit pouvoir être évaluée. Cela se traduit en nombre de point de complexité. Plusieurs méthodes existent pour l’évaluation. La plus utilisée reste le Planning Poker.
• Small: Les User Stories sont des découpages de groupes de fonctionnalités plus larges que l’on appelle Epic. Plus ces User Stories sont découpées finement, plus elles prennent de la valeur.
• Testable : Enfin, vos User Stories devront pouvoir faire l’objet de tests pour valider leurs critères d’acceptation.

Pour conclure

Vous l’aurez compris, rédiger une User Story de qualité est un processus complexe qui nécessite de la rigueur et une très bonne compréhension du besoin client. C’est pourquoi c’est généralement le Product Owner qui représente le client dans l’équipe Scrum qui est en charge de cette rédaction ; En effet, son rôle est de veiller à ce que les besoins clients ne soient jamais perdus de vue pendant un sprint de développement. Cependant, toutes les équipes ne comprennent pas de PO, toutes les agences ne fonctionnent pas de la même manière. Cependant, quel que soit votre place dans l’équipe, vous serez en contact avec ces outils. En comprendre le processus de rédaction est donc capital.

Crédit photo: <a href= »https://fr.freepik.com/photos/bureau »>Bureau photo créé par freepik – fr.freepik.com</a>