Qu’est-ce que les « User Stories » et à quoi ça sert ?
Dans le domaine du développement de logiciels et de la gestion de produits, une user story est une description informelle en langage naturel d’une ou plusieurs fonctionnalités d’un système logiciel. Elle fait partie d’une approche agile qui passe de l’écriture des exigences à la discussion.
Dans cet article, la société d’externalisation offshore Bocasay vous explique en quoi consistent les user stories et à quoi elles servent.
Définition : qu’est-ce qu’une « user story » ?
Une user story est un outil utilisé dans le développement logiciel agile pour capturer une description des fonctionnalités du logiciel du point de vue de l’utilisateur final.
Les user stories décrivent les types d’utilisateurs, ce qu’ils veulent et pourquoi.
Les user stories vous permettent de créer de courtes descriptions de vos besoins.
Les user stories sont souvent enregistrées sur des fiches, des post-its ou des logiciels de gestion de projet. Selon le projet, les user stories peuvent être rédigées par différentes parties prenantes, telles que :
- les clients,
- les utilisateurs,
- les responsables
- et les membres de l’équipe de développement.
Au sein de la méthode Srcum, c’est le Product Owner qui sera chargé de rédiger les user stories.
Pourquoi créer des user stories ?
Elles permettent de donner un cadre et un contexte important pour votre équipe, ce qui permet de comprendre les valeurs qu’elles apportent aux différentes tâches.
Les user stories sont centrées sur l’utilisateur. Vous gardez ainsi votre équipe concentrée sur les tâches de vérification avec une liste de tâches.En outre, la série de stories permet à l’équipe de se focaliser sur la résolution des problèmes réels des utilisateurs.
Les user stories boostent l’esprit d’équipe. Une fois l’objectif final défini, les membres de l’équipe peuvent travailler ensemble pour déterminer la meilleure façon de servir les utilisateurs et d’atteindre cet objectif.
Les user stories améliorent la dynamique du projet. Au fur et à mesure que l’histoire (story) se déroule, l’équipe de développement apprécie les petits défis et les triomphes qui créent une dynamique positive.
Une user story agile se compose de trois parties, selon Ron Jeffries, informaticien américain et co-fondateur de l’Extreme programming :
- La carte : Une description de l’histoire. Utilisé comme plan et rappel.
- La conversation : Le dialogue de l’histoire utilisé pour étoffer les détails de l’histoire
- La confirmation : Un test qui communique et documente les détails qui peuvent être utilisés pour déterminer si une histoire est complète.
Les user stories présentent de nombreux avantages, mais le plus important est peut-être que chaque user story devient un espace réservé pour les conversations futures.
Les étapes à suivre pour écrire une user story digne de ce nom
Les utilisateurs finaux sont les personnes idéales pour écrire des user stories.
Lors de l’utilisation de Scrum, le Product Owner donne la priorité aux user stories dans le backlog du produit. Les stories les plus prioritaires sont extraites du backlog et traitées dans les sprints Scrum.
La clé pour écrire des user stories efficaces est de déterminer qui, quoi et pourquoi.
1. Définissez l’utilisateur final
Qui utilisera votre produit ?
Avant d’écrire une User Story, vous devez savoir qui sont les utilisateurs finaux de votre produit. Et, plus important encore, quels sont les besoins que vous essayez de couvrir.
Pour des resultats optimisés, approfondissez votre audience. Au lieu de simplement nommer les utilisateurs par rôle (par exemple « un conducteur »), essayez de créer une sorte de « buyer persona ».
👉 Ne considérez pas vos utilisateurs uniquement comme des clients toujours extérieurs. En effet, la plupart de vos stories en parlent. Cependant, il est également vrai que les utilisateurs internes tels que les administrateurs et les éditeurs doivent être pris en compte.
👉 Faites preuve d’empathie. Donnez un nom à « l’utilisateur ». Pensez à leurs habitudes mobiles, aux problèmes que votre application aide à résoudre et à la façon dont vous pouvez rendre ce processus plus facile et plus rapide.
Exemple de titre de story efficace qui met en exergue l’utilisateur cible et son action : « Clothidle de la comptabilité recherche une fiche client »
2. Spécifiez ce que l’utilisateur final veut
Qu’est-ce que vos utilisateurs finaux attendent de votre produit ?
Les principales règles à garder à l’esprit lors de l’écriture des user stories Kanban ou des actions Scrum sont :
👉 Une action par story. Décrivez l’intention, pas la fonctionnalité. Par exemple, au lieu de « Je veux gérer mon profil », je crée plusieurs stories telles que :
- « Je veux pouvoir m’inscrire ».
- « Je veux télécharger une photo de profil ».
- « Je veux associer un moyen de paiement à mon profil. »
Chaque histoire a une valeur différente.
👉 Faites court. L’utilisateur ne se soucie pas de la bibliothèque qu’il utilise pour parcourir la liste des éléments. Laissez donc de côté tous les détails techniques.
𝕊𝕒𝕧𝕚𝕖𝕫-𝕧𝕠𝕦𝕤 𝕢𝕦𝕖 𝕧𝕠𝕦𝕤 𝕡𝕠𝕦𝕧𝕚𝕖𝕫 𝕗𝕒𝕚𝕣𝕖 𝕒𝕡𝕡𝕖𝕝 𝕒̀ 𝕦𝕟𝕖 𝕖́𝕢𝕦𝕚𝕡𝕖 𝟙𝟘𝟘% 𝕕𝕖́𝕕𝕚𝕖́𝕖 𝕒̀ 𝕧𝕠𝕤 𝕡𝕣𝕠𝕛𝕖𝕥𝕤 𝕕𝕖 𝕕𝕖́𝕧𝕖𝕝𝕠𝕡𝕡𝕖𝕞𝕖𝕟𝕥 𝕚𝕟𝕗𝕠𝕣𝕞𝕒𝕥𝕚𝕢𝕦𝕖 𝕒̀ 𝕕𝕚𝕤𝕥𝕒𝕟𝕔𝕖 ? 𝔹𝕠𝕔𝕒𝕤𝕒𝕪, 𝕖𝕩𝕡𝕖𝕣𝕥 𝕕𝕒𝕟𝕤 𝕝’𝕖𝕩𝕥𝕖𝕣𝕟𝕒𝕝𝕚𝕤𝕒𝕥𝕚𝕠𝕟 𝕠𝕗𝕗𝕤𝕙𝕠𝕣𝕖, 𝕞𝕖𝕥 𝕒̀ 𝕧𝕠𝕥𝕣𝕖 𝕕𝕚𝕤𝕡𝕠𝕤𝕚𝕥𝕚𝕠𝕟 𝕤𝕖𝕤 𝕞𝕖𝕚𝕝𝕝𝕖𝕦𝕣𝕤 𝕥𝕒𝕝𝕖𝕟𝕥𝕤 𝕡𝕠𝕦𝕣 𝕧𝕠𝕦𝕤 𝕒𝕔𝕔𝕠𝕞𝕡𝕒𝕘𝕟𝕖𝕣 𝕕𝕒𝕟𝕤 𝕧𝕠𝕥𝕣𝕖 𝕖́𝕧𝕠𝕝𝕦𝕥𝕚𝕠𝕟 𝕖𝕥 𝕧𝕠𝕤 𝕡𝕖𝕣𝕗𝕠𝕣𝕞𝕒𝕟𝕔𝕖𝕤 ? ℂ𝕠𝕟𝕥𝕒𝕔𝕥𝕖𝕫-𝕟𝕠𝕦𝕤 𝕕𝕖̀𝕤 𝕒𝕦𝕛𝕠𝕦𝕣𝕕’𝕙𝕦𝕚 𝕖𝕥 𝕕𝕖𝕞𝕒𝕟𝕕𝕖𝕫 𝕧𝕠𝕥𝕣𝕖 𝕕𝕖𝕧𝕚𝕤 𝕘𝕣𝕒𝕥𝕦𝕚𝕥 !
3. Décrivez les avantages du produit
Imaginez que vous êtes l’utilisateur final et que vous vous adressez au développeur du produit. Expliquez aux développeurs les avantages que l’utilisateur finale va retirer de l’utilisation de ce produit.
Par exemple, dans le cas d’une application de commande en ligne :
En tant que client, je veux recevoir des notifications lorsqu’il y a de nouvelles offres chaudes afin de ne jamais manquer les meilleures affaires.
👉 Les utilisateurs sont avertis, ils utilisent l’application plus souvent, le taux de rétention augmente.
En tant que gérant d’un site de vêtement en ligne, je souhaite compléter la description du produit avec une photo du vêtement porté afin de permettre aux clients de se projeter.
👉 Les utilisateurs sont satisfaits de pouvoir voir les photos, les ventes augmentent et les revenus également.
4. Listez les critères d’acceptation des stories
Les critères d’acceptation définissent les limites des histoires d’utilisateur. Ils sont utilisés pour confirmer qu’une histoire est terminée et fonctionne comme prévu.
Ces critères peuvent être :
👉 Fonctionnels : identification des tâches, des fonctions ou des processus d’entreprise de l’utilisateur.
👉 Non fonctionnels : liés à la conception et à l’interface utilisateur.
👉 De performance : liés à des mesures de performance, par exemple, le temps de chargement.
✅ Les avantages des user stories
Les principaux avantages que nous pouvons citer sont :
Une plus grande flexibilité : les user stories sont moins techniques et peuvent être adaptées à l’évolution de l’environnement.
Format simplifié : les user stories sont rédigées en langage clair. Cela élimine la confusion et aide à mieux comprendre ce que veulent les clients.
Une collaboration améliorée : lorsque les membres de l’équipe sont alignés sur un objectif commun, ils collaborent mieux et plus facilement avec les autres parties prenantes du projet.
Bien que la rédaction de user stories présente un grand nombre d’avantages, les Product Owners doivent également tenir compte des inconvénients potentiels.
❌ Les inconvénients des user stories
Voici quelques pièges à éviter dans la création de user stories :
Des stories incomplètes : bien que la formulation soit censée être informelle, les histoires d’utilisateurs sont parfois trop vagues et omettent les détails nécessaires.
Une vision étroite : les user stories se concentrent sur une seule exigence, ce qui les rend difficiles à mettre à l’échelle et peut amener les équipes à perdre de vue la vue d’ensemble.
Le temps : rédiger de bonnes user stories prend du temps. Cela nécessite des recherches approfondies et une communication régulière avec les parties prenantes, ce qui est souvent négligé.
Avant de commencer vos user stories, prenez le temps d’identifier les risques et les lacunes potentielles et trouver dès à présent comment les résoudre.