Comment écrire des user stories : un guide complet

Les user stories sont un élément essentiel du développement logiciel agile approprié : examinons leur rôle et apprenons à écrire des user stories.

Les frameworks agiles sont un moyen populaire et efficace de structurer le développement de logiciels et de déléguer des tâches. La rédaction de user stories (à ne pas confondre avec la rédaction d'un témoignage) est un outil du développement agile qui permet aux développeurs de comprendre ce qui doit être fait et comment répondre à une exigence. Cela en fait un point de départ très important - mais cela signifie également qu'ils doivent être construits avec soin. Voici ce que vous devez savoir.

Qu'est-ce qu'une User Story ?

C'est un terme utilisé dans le développement de logiciels dans un cadre agile. La user story est généralement considérée comme la plus petite unité du projet agile ou la première étape pour répondre à une exigence. Ils sont créés lorsqu'un projet est entièrement planifié.

Alors, qu'est-ce que cela signifie exactement? Chaque fonctionnalité logicielle a (ou devrait avoir) un but particulier lorsqu'elle est ajoutée à un projet. Cet objectif devrait influencer l'ensemble de son développement et la façon dont il est intégré dans le cadre général. Les développeurs peuvent faire référence à cet objectif chaque fois que nécessaire pour prendre des décisions, en particulier sur la manière de décomposer les objectifs et les priorités. La « user story » est simplement une façon de décrire le but d'une fonctionnalité.

Les user stories sont écrites du point de vue de l'utilisateur, généralement en une phrase ou deux. Ils capturent le point de vue de l'utilisateur et ce qu'il veut faire. Une fois terminées, les bonnes histoires d'utilisateurs sont un moyen facile de parler des objectifs stratégiques, des fonctionnalités qui peuvent être supprimées en toute sécurité ou doivent être ajoutées, et bien plus encore.

Comment écrire une histoire d'utilisateur

Étape 1. Obtenir une entrée

Obtenez les commentaires des propriétaires, des utilisateurs potentiels et des chefs de projet. Une histoire d'utilisateur forte nécessite beaucoup d'entrées pour être précise. Obtenez des explications claires de ces groupes sur ce qu'ils veulent faire. N'oubliez pas que cela ne devrait pas se traduire directement dans la user story, mais fournira les informations nécessaires. Un propriétaire peut dire : "J'ai besoin que les gens puissent payer avec PayPal sur mon application", ce qui est très utile, mais pas la user story elle-même.

Étape 2. Décidez comment les user stories sont créées

Cela dépend de votre flux de travail. Dans les premières étapes, les user stories sont capturées sur des fiches ou des post-it lors de la planification du cadre général. Plus tard, ils sont intégrés dans un logiciel de gestion de projet. Certains membres de l'équipe ignorent l'étape du post-it, tandis que d'autres s'y fient, selon ce qui vous convient.

Étape 3. Définir, définir, définir

Définir l'utilisateur : avec l'entrée, vous pouvez maintenant définir l'utilisateur. Gardez à l'esprit qu'il ne s'agit pas toujours de l'utilisateur final des fonctionnalités du produit ; cela peut varier selon le type d'utilisateur. Créez des personas d'utilisateur si nécessaire. Définissez l'action entreprise par l'utilisateur et définissez l' objectif de l'utilisateur en effectuant cette action. Incluez ces informations clés lors de l'élaboration de votre user story pour parler à votre public cible.

Étape 4. Écrivez l'histoire

Commencez à écrire votre histoire d'utilisateur, elle ne devrait être qu'une phrase ou deux afin de retenir l'attention du lecteur. Il est tentant d'être précis et technique ici, mais un langage large, comme les énoncés de mission, peut être utile. Clarifiez l'histoire et assurez-vous qu'elle peut être résolue ou complétée, afin que vous puissiez regarder en arrière et confirmer : "Oui, les utilisateurs peuvent maintenant le faire !".

Étape 5. Diviser en étapes supplémentaires

Les user stories peuvent nécessiter plusieurs étapes pour atteindre l'objectif final, ce qui peut nécessiter un peu de restructuration en fonction du cadre agile que vous utilisez. N'oubliez pas que la user story est toujours la plus petite unité du framework. À ce niveau granulaire, la mise en œuvre des user stories devrait prendre plusieurs jours.

S'il semble qu'ils prendront beaucoup plus de temps, c'est un signe à revoir et à voir si l'expérience utilisateur doit être davantage décomposée et restructurée. Si de nouvelles exigences sont ajoutées, elles devront également être décomposées en user stories. Bien que ces quelques phrases soient au cœur de récits d'utilisateurs efficaces, elles peuvent également être développées au fur et à mesure du développement. Regardons cela de plus près.

Quels sont les 3 C dans les User Stories ?

Card : La phase Card consiste à écrire des user stories pour l'équipe de développement en une phrase ou deux. C'est ce qu'on appelle une carte parce que les histoires d'utilisateurs ont été écrites à l'origine sur des fiches, et de nombreuses équipes préfèrent encore le faire de cette façon. La carte est au cœur de ses exigences logicielles spécifiques et le point de départ de toutes les discussions. Il est également facile de vérifier si votre user story est trop longue - si elle ne peut pas tenir sur une fiche que tout le monde peut lire, elle doit être raccourcie.

Conversation : Une fois les phrases de la carte créées, il est temps de peaufiner les détails. Cela commence généralement par une série de questions entre les développeurs, telles que "Combien de temps cela prendra-t-il pour être implémenté ?" ou "Comment pouvons-nous intégrer cette action ?" ou "Cette user story est-elle essentielle ici ?" Etc.

Cet examen approfondi de la user story donnera probablement des questions supplémentaires à poser aux chefs de projet et aux propriétaires de produit, qui devraient être amenés à la conversation si nécessaire. Au fur et à mesure que la conversation se poursuit, les user stories peuvent être modifiées, affinées, fusionnées ou supprimées jusqu'à ce que tout le monde soit sur la même page. Au fur et à mesure que les user stories sont finalisées, elles sont déplacées vers la mise en œuvre, signe que la conversation est essentiellement terminée.

Confirmation : La confirmation concerne les tests d'acceptation, c'est-à-dire les critères d'acceptation. Une fois que le changement a été mis en œuvre et que les développeurs signalent qu'il est prêt – que la user story a été satisfaite – il est temps de le tester.

Les tests d'acceptation doivent être créés avec l'apport du propriétaire du produit et être directement liés à la user story. Dans le meilleur des cas, c'est un utilisateur qui essaie simplement de faire ce que la user story indique et de voir s'il le peut. Mais les tests d'acceptation peuvent varier et ne sont pas toujours faits avec les histoires d'utilisateurs à l'esprit comme ils le devraient. Si cela crée un problème, il est temps de revenir à l'étape Conversation jusqu'à ce que les tests d'acceptation et les user stories soient correctement alignés. Si tous les tests d'acceptation sont terminés, la user story est ravie. Il est maintenant temps de passer à l'étape suivante du développement du produit ou de publier la fonctionnalité.

Un 4ème C ? : Fait intéressant, certains affirment qu'il existe un 4ème C essentiel : Contexte. Dans ce cas, la user story est vue aux côtés des autres user stories dans le cadre plus large du projet. Ici, les développeurs demandent si la user story complète bien les autres user stories ou s'il y a des lacunes - des choses que l'utilisateur doit faire ou comprendre qui ont été manquées entre les user stories.

Idéalement, cela est repéré pendant la phase de conversation, mais cela ne se produit pas toujours. Certaines équipes de développement peuvent souhaiter un examen final de la manière dont la user story terminée s'intègre dans l'ensemble et si d'autres travaux doivent être effectués.

Qu'est-ce qu'un bon format pour une user story ?

Passons en revue deux techniques de formatage qui sont très utiles lors de la création de phrases de user story. La première est très simple : « Qui, quoi et pourquoi ? » Dans un modèle de phrase, cela peut être décrit comme ceci :

En tant que [Qui est l'utilisateur], je veux [Ce que l'utilisateur veut] (pour que [Pourquoi l'utilisateur le veut]).

Ce modèle peut également être formulé comme suit : "En tant que [rôle], je veux [action], (pour que [bénéfice])", pour une terminologie simplifiée. Suivre ce format de base suffit à créer la majorité des user stories. C'est généralement tout ce dont vous avez besoin et cela peut vous faire gagner beaucoup de temps lorsqu'il est utilisé pour chaque user story.

Parfois, cependant, les user stories sont plus difficiles à définir dans des projets plus complexes. Dans ce cas, une deuxième technique de modèle de user story peut être utile. Cela s'appelle INVEST, un acronyme qui signifie :

• Indépendant : Les histoires doivent être entièrement indépendantes les unes des autres, et les histoires doivent donc pouvoir être travaillées dans le désordre.
• Négociable : les histoires doivent être conçues pour être modifiées pendant la partie Conversation du processus.
• Valable : la user story doit démontrer une valeur claire pour le projet. Si ce n'est pas le cas, cela peut être un gaspillage de ressources.
• Estimable : Une user story doit être mesurée en valeur et en priorisation pour aider à décider sur quoi travailler par ordre d'importance.
• Petit : Les user stories doivent être la plus petite unité de fonctionnalité et doivent autrement être décomposées davantage.
• Testable : La user story doit être énoncée de manière testable lors du processus de Confirmation.

FAQ sur la façon d'écrire des histoires d'utilisateurs

Vous pourriez également être intéressé par notre guide sur la façon de rédiger une critique de jeu.