Les User Stories sont un élément vital du développement logiciel agile. Les logiciels sont destinés à être utilisés par les utilisateurs et les développeurs doivent garder leurs exigences à l’esprit. C’est ainsi qu’un logiciel efficace centré sur le client peut être construit.
Si vous travaillez dans une équipe qui suit la technologie de développement logiciel agile, vous devez être conscient du fait que, quel que soit votre rôle dans l’équipe, on peut vous demander d’écrire des user stories pour le produit que votre équipe est en train de construire.
Dans ce guide, j’ai partagé certaines des techniques les plus efficaces que vous pouvez utiliser pour écrire de grandes histoires d’utilisateur, mais avant cela, laissez-moi vous informer rapidement sur les histoires d’utilisateur et leurs besoins.
Qu’est-ce qu’une User Story ?
Dans le cadre agile, les User Stories sont la plus petite unité de travail. Les User Stories sont les explications informelles écrites du point de vue de l’utilisateur du produit.
En termes simples, c’est une petite description qui dépeint le résultat et les attentes du produit.
Ici, le terme « client » ne représente pas les clients réels du produit, il peut s’agir de n’importe quel membre de l’équipe ou de l’organisation. La seule condition préalable à l’écriture d’une histoire d’utilisateur est que l’individu doit avoir la perspective de l’utilisateur final. Parce qu’une User Story est un objectif final.
Pourquoi avons-nous besoin de User Stories ?
Comme mentionné ci-dessus, les User Stories sont la représentation des attentes d’un individu. Par conséquent, les User Stories offrent de nombreux avantages à l’équipe produit.
Certains d’entre eux sont mentionnés ci-dessous :
Construit un lien entre les clients du produit et l’équipe produit. C’est parce que les User Stories proviennent directement du consommateur du produit et cela aide les développeurs et les gestionnaires à rester informés des besoins et des attentes réels.
Rend le produit plus centré sur le client. Un aperçu des attentes de l’utilisateur : Les User Stories aident l’équipe de conception à avoir un aperçu de l’utilisateur pour lequel le produit est conçu. Globalement, cela permet d’améliorer l’interface utilisateur du produit.
Réduit le nombre de révisions : Puisque l’équipe produit a une idée exacte de la base d’utilisateurs et de leurs besoins dans tous les aspects possibles du produit.
Réduit la confusion : Les User Stories donnent une idée précise à l’équipe produit de ce qu’elle doit réellement construire et de toutes les fonctionnalités que les utilisateurs attendent.
De meilleurs résultats : Les User Stories donnent à l’équipe une compréhension claire de ce qui doit être ajouté ou amélioré, et ce d’une manière simple et descriptive. Cela permet à l’équipe de penser plus efficacement dans tous les aspects.
Construit un flux : Dans un projet, il y a plusieurs user stories, une fois que l’équipe a terminé une histoire, cela la remplit de joie et d’un sentiment de petite victoire. Ces sentiments encouragent l’équipe à relever d’autres défis mentionnés dans les user stories. Globalement, cela aide l’équipe à être plus productive.
Comment les User Stories sont considérées
Une fois que les user stories sont préparées et ajoutées aux sprints. L’équipe de développeurs prend en compte chaque histoire d’utilisateur dans leur backlog et les considère dans leur workflow.
Toutes ces histoires d’utilisateurs aident l’équipe à s’améliorer en matière d’estimation, de planification des délais et lui donnent la possibilité de créer un produit plus précis en fonction des utilisateurs.
Comme mentionné ci-dessus, les user stories aident l’équipe à obtenir le point de vue de l’utilisateur. Par conséquent, l’équipe est consciente du fait que « pour qui le produit est construit » tout au long du projet.
Techniques de rédaction des user stories
Si vous tenez compte de tous les points mentionnés ci-dessous, vous serez en mesure de générer d’excellentes histoires d’utilisateur :
Décrire les tâches de manière spécifique
Lorsque vous rédigez les user stories, vous devez vous assurer que toutes les tâches sont mises en évidence individuellement. Évitez de mélanger deux tâches ou sous-tâches.
Soyez bref mais explicatif
Bien que les user stories doivent être courtes, vous devez vous assurer qu’elles sont également simples. Ne faites pas l’impasse sur le contenu dans le seul but de rendre vos user stories courtes.
Une seule phrase peut aider l’équipe concernée à se faire une idée exacte de votre attente ou de votre problème.
Incluez le processus (si nécessaire)
Si vous mettez en évidence une tâche nouvelle ou différente, vous devez inclure le processus complet avec les étapes mentionnées spécifiquement afin que, pendant le développement, la personne concernée ait un flux de travail continu.
Évitez les suppositions
Si vous êtes membre d’une équipe et que vous devez rédiger des user stories, il est conseillé d’éviter de créer des user stories basées sur des suppositions. Vous devez investir du temps pour entrer en contact avec le client du produit et essayer de comprendre ses préoccupations et ses attentes.
N’oubliez pas que les user stories ne sont pas des formalités. Elles permettent au produit d’être plus centré sur le client et plus efficace.
Se concentrer sur les utilisateurs finaux individuels
Si le produit a plusieurs utilisateurs finaux, vous devez éviter de créer des user stories communes, essayez plutôt de créer des user stories axées sur chaque type d’utilisateurs.
Rendez les user stories accessibles à tous
Vous devez vous assurer que chaque user story est visible pour chaque membre de l’équipe.
Comprendre les trois Ws (Who, What ,and Why)
En rédigeant les user stories, vous devez vous assurer que votre histoire couvre les trois W (Who, What, and Why).
Ici, « Qui » représente l’aspect le plus important de l’histoire, c’est-à-dire, qui sera l’utilisateur final de l’histoire. Par exemple, si vous voulez inclure le point de vue du directeur du magasin, alors vous devez inclure le directeur du magasin dans l’histoire.
Ce qui représente ici la préoccupation/le problème ou les attentes de l’utilisateur final (Qui).
En outre, vous devez inclure le « pourquoi », qui représente la raison derrière le problème/l’attente de l’utilisateur final.
Exemples
Si vous commencez à écrire des user stories, vous pouvez consulter les exemples ci-dessous :
En tant que superviseur, je veux vérifier périodiquement les progrès de mes juniors, afin de pouvoir leur fournir des évaluations.
En tant que visiteur du portail d’emploi, je veux une liste d’offres d’emploi sur le tableau de bord afin de ne pas avoir à hésiter entre différentes options.
En tant que professionnel du marketing, je veux consulter les graphiques d’engagement afin de pouvoir analyser plus efficacement.
En tant que membre abonné au site web d’un restaurant, je veux recevoir toutes les notifications des dernières offres afin de n’en manquer aucune.
En tant que médecin senior, je veux accéder à l’activité de mes infirmières afin de pouvoir décider de leurs incitations.
Conclusion
Les user stories inspirent l’équipe produit et lui permettent de créer un produit plus efficace. Dans l’ensemble, les histoires d’utilisateurs aident à la fois l’équipe de développement et les utilisateurs finaux, donc vous ne pouvez pas vous permettre d’ignorer les histoires d’utilisateurs.
Écrire des histoires d’utilisateur juste pour la formalité pourrait être dangereux pour le projet parce que l’équipe de produit pourrait sauter sur certaines des attentes de l’utilisateur final.
Vous devez créer de bonnes histoires d’utilisateur et le guide ci-dessus vous aidera à générer de bonnes histoires d’utilisateur. Il est recommandé d’essayer de générer quelques exemples d’histoires d’utilisateurs avant de se lancer dans les histoires de produits pratiques.
