Créer des user stories

« Le client a toujours raison ». Bien que cette expression soit souvent contestée dans le monde de la vente, ce n’est pas une mauvaise idée de la garder à l’esprit pour les projets agile. Dans les faits, la satisfaction du client est considérée comme la priorité la plus élevée dans le Manifeste agile.

Dans la méthodologie agile, il est courant d’inclure les commentaires des utilisateurs dans le processus de développement. Les équipes agile tiennent compte de ce point de vue externe pour s’assurer qu’elles sont sur la bonne voie et que le livrable final répondra aux besoins du client.

Lors de la décomposition des projets en une structure de travail agile, les équipes commencent par explorer le point de vue du client. Pour cela, elles créent généralement des user stories.

Dans cet article, nous aborderons les user stories : ce qu’elles sont, comment les rédiger, ainsi que leurs avantages et inconvénients. Nous partagerons également un modèle de plan de projet agile pour vous aider à gérer vos projets agile de bout en bout.

Si vous souhaitez exploiter la puissance d’un système logiciel robuste pour vos projets agile et rationaliser tous vos workflows agile en un seul endroit, essayez Wrike gratuitement dès aujourd’hui.

Qu’est-ce qu’une user story ?

Une user story est une brève explication écrite d’un besoin particulier d’un utilisateur et de la manière dont il peut être satisfait dans le cadre du cycle de développement agile. Ces stories sont conçues pour se concentrer sur l’utilisateur final et sont généralement rédigées dans des termes simples pour faciliter leur compréhension.

Chaque user story correspond à une demande courte, traitée en une seule itération agile ou en un seul sprint, d’une durée habituelle d’une à deux semaines. Les équipes mesurent la complexité de leurs user stories avec des story points, ce qui les aide à estimer avec précision la durée d’une demande particulière.

Dans la méthodologie agile, une collection de user stories est appelée un epic. Un propriétaire de produit est responsable de la gestion de l’epic, mais il peut être rédigé par n’importe quel membre de l’équipe de développement agile.</0>

Une user story ressemble à un cas d’utilisation mais n’est pas aussi détaillée. La user story est une description très brève d’un élément d’action planifié, tandis que le cas d’utilisation contient généralement des sections supplémentaires telles que des conditions de satisfaction, différents scénarios d’utilisation d’un produit, et des diagrammes de workflow.

L’historique des user stories dans la méthodologie agile

Jetons un coup d’œil à l’historique de la méthodologie agile pour comprendre comment les user stories ont vu le jour.

En 2001, 17 experts indépendants issus du secteur du développement logiciel se sont réunis pour former l’Agile Alliance et ont publié le Manifeste agile. Ce document contenait 12 principes, dont le premier était :

« Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. »

Les user stories sont une extension évidente de ce principe, mettant en évidence l’importance de l’utilisateur final et de répondre à ses attentes.

Les cadres Scrum et Extreme Programming relèvent de la méthodologie agile.

Scrum 

Le concept de Scrum est né dans les années 1990, mais ce n’est qu’en 2002 que la Scrum Alliance a été fondée par Mike Cohn, Esther Derby et Ken Schwaber.

Dans ce cadre, un Scrum Master dirige un petit groupe vers le succès du projet. Les équipes Scrum travaillent généralement en cycles de sprint de deux semaines, au cours desquels elles travaillent sur des user stories. Ces petites unités de travail aident à orienter les sprints et les réunions Scrum quotidiennes.

Extreme Programming (XP)

XP remonte également aux années 1990, lorsqu’il a été fondé par Kent Beck et développé plus tard par Ward Cunningham et Ron Jeffries.

Selon l’Agile Alliance, les user stories ont en fait vu le jour dans le cadre XP, où elles étaient décrites comme des « cartes de jeu » dans la planification de projet. Grâce à des sprints de travail courts, une planification itérative constante et une collaboration étroite avec les parties prenantes, XP convient parfaitement aux situations où les clients ne savent pas exactement ce qu’ils veulent.

Exemples de user stories

Voyons maintenant ce que comporte une user story. Dans le cadre de l’approche agile, le format des user stories est assez simple, décrivant le « qui », « quoi » et « pourquoi » d’une exigence particulière.

• Qui veut quelque chose ?
• Que veulent-ils ?
• Pourquoi le veulent-ils ?

Jetez un œil à ce modèle de user story, qui décrit les trois éléments ci-dessus en une phrase concise :

« En tant que [persona], je veux [action], pour pouvoir [bénéfice]. »

Pour chaque story, l’auteur inclut un persona utilisateur, l’action qu’il souhaite entreprendre ou la capacité qu’il souhaite acquérir, et le bénéfice qu’ils espèrent en retire. Voici quelques exemples de stories appliquées à trois personas différents :

Exemple 1 : joueur en ligne

« En tant que joueur en ligne, je veux avoir une option multijoueur pour pouvoir jouer en ligne avec des amis. »

Exemple 2 : responsable d’une équipe de design

« En tant que responsable d’équipe de design, je souhaite organiser des ressources pour pouvoir suivre de nombreux projets créatifs. »

Exemple 3 : acheteur en ligne

« En tant qu’acheteur en ligne, je veux filtrer mes recherches pour trouver des produits de meilleure qualité rapidement. »

Maintenant que vous savez à quoi ressemble un exemple de user story, mettez-vous au travail pour en créer une.

5 étapes pour rédiger des user stories

Vous voulez des conseils pratiques sur la rédaction des user stories ? Ces cinq étapes vous serviront de guide :

Étape 1 : définir les critères d’acceptation

La définition de ce qui est terminé est l’ensemble des critères qui doivent être remplis pour que votre user story soit considérée comme terminée. Définissez les critères spécifiques d’acceptation et utilisez-les comme liste de contrôle.

Étape 2 : décider des personas utilisateur

Menez des recherches approfondies sur les utilisateurs en créant des enquêtes, en organisant des groupes de discussion et en consultant les forums d’utilisateurs. Analysez vos données et recherchez des modèles pour identifier vos personas clés.

Étape 3 : créer des tâches

Décomposez votre story en plusieurs tâches pour mieux la gérer. En cas d’exigence complexe, vous pouvez ajouter des sous-tâches. Incluez des descriptions détaillées pour aligner votre équipe sur les exigences de chaque tâche.

Étape 4 : mapper les story 

Utilisez le story mapping pour structurer le travail dans un grand processus. Dans ce cas, vos stories prendront la forme d’étapes organisées.

Vous pouvez créer vos cartes de stories en utilisant des notes manuscrites, des fiches ou un logiciel de gestion de projet.

Étape 5 : demander des commentaires

Discutez avec les utilisateurs et les clients potentiels pour savoir ce qu’ils veulent. Demandez-leur leur avis sur les produits existants ou s’ils ont des suggestions de nouvelles fonctionnalités. Intégrez ces commentaires à votre user story.

Il est primordial de prendre en compte le point de vue des utilisateurs, car vous pouvez intégrer ces commentaires dans votre user story.

Qu’est-ce qui caractérise une bonne user story ?

Votre user story agile est terminée et prête à être révisée. Il est temps de réunir vos équipes agile pour évaluer la qualité de votre story via l’ acronyme INVEST. Voici ce que cela signifie :

• Indépendante : la user story doit être indépendante de toutes les autres. Comme elles ne sont pas liées, elles peuvent être traitées dans n’importe quel ordre.
• Négociable : une user story doit être suffisamment flexible pour encourager et permettre la négociation entre le client et le propriétaire du produit.
• Valeur : quelle valeur apporte la user story ? Si vous ne trouvez aucune valeur ou fonctionnalité souhaitée, la story ne doit pas être réalisée.
• Estimable : vous devez pouvoir estimer la durée d’une user story pour pouvoir gérer efficacement votre temps.
• Suffisamment petite : la story doit être suffisamment petite pour être terminée en un seul sprint.
• Testable : vous devez pouvoir tester votre user story conformément aux normes d’assurance qualité et obtenir une confirmation par les tests d’acceptation (par exemple, les tests bêta).

Si une user story ne satisfait pas la liste de contrôle INVEST, elle doit être réécrite ou supprimée de l’epic. Cependant, si c’est le cas, les membres de votre équipe peuvent se mettre au travail. Organisez des réunions agile quotidiennes pour vérifier leur progression et évaluer s’ils sont sur la bonne voie pour terminer les user stories au cours du sprint.

Stories grandes ou petites

Vous ne savez pas si votre équipe devrait se concentrer sur des user stories grandes ou petites ? Bien que les grandes stories puissent fournir plus d’informations, les petites stories présentent plusieurs avantages clés :

• Concentration : étant donné que les petites stories ont un objectif limité, elles ne seront pas trop détaillées, contrairement aux stories plus grandes. Une story plus petite permet d’éviter toute confusion afin que votre équipe puisse mieux collaborer et travailler plus rapidement. Allez à l’essentiel !
• Risque réduit : plus la story est grande, plus le risque que votre équipe n’ait pas un livrable prêt à la fin du sprint agile est élevé, car vos ressources seront dispersées. Par exemple, un développeur avec des compétences spécifiques peut être le seul à pouvoir terminer les stories de votre équipe. Cependant, si vous les décomposez en stories plus petites, vous évitez que cette personne ne s’épuise.
• Transparence : les user stories plus petites permettent à votre équipe de mieux voir et suivre les progrès. Les stories plus grandes ont différents éléments changeants, il sera donc plus difficile d’expliquer l’avancement de votre projet lors des réunions quotidiennes et des échanges avec les parties prenantes concernées.

Avantages des user stories

Pourquoi écrire des user stories en premier lieu ? Parce qu’elles offrent de nombreux avantages pour un projet agile. Voici quelques exemples :

• Format simplifié : les user stories sont rédigées dans un langage concretet facile à comprendre. Cela permet d’éviter toute confusion et de mieux comprendre les besoins du client.
• Flexibilité et créativité accrues : les user stories n’entrent pas dans les détails techniques, elles peuvent donc s’adapter à des situations changeantes.
• Collaboration améliorée : lorsque les membres de l’équipe sont alignés sur un objectif, ils peuvent mieux travailler ensemble et collaborer facilement avec les autres parties prenantes du projet.

Malgré un nombre important d’avantages, un chef de produit doit aussi considérer les éventuels inconvénients des user stories.

Inconvénients des user stories

Voici quelques pièges à éviter dans les user stories :

• User stories incomplètes : même si le langage se veut informel, certaines user stories manquent parfois de clarté et omettent des détails nécessaires.
• Temps insuffisant : rédiger une bonne story agile prend du temps, car cela nécessite des recherches approfondies. Une communication régulière et une compréhension partagée avec les parties prenantes sont également nécessaires et parfois négligées.
• Vision étroite : les user stories se concentrent sur une seule exigence, elles peuvent donc être difficiles à adapter et les équipes peuvent parfois perdre de vue la situation dans son ensemble (dans ce cas, un epic).

Avant de commencer votre story, prenez le temps d’identifier les risques ou inconvénients potentiels. Discutez avec votre équipe pour décrire comment vous avez l’intention de contrer les risques.

Améliorez vos user stories avec Wrike

Maintenant que vous savez comment créer une user story, voyons comment décomposer votre projet. Wrike a la solution idéale pour cela.

Avec le logiciel de Wrike, les équipes peuvent facilement appliquer les méthodologies agile en utilisant des workflows personnalisés, des tableaux Kanban, et des modèles prédéfinis. Ces fonctionnalités permettent aux équipes de démarrer rapidement les projets, de visualiser et de suivre leur avancement, de gérer le temps, d’organiser les tâches et de collaborer efficacement. Les équipes de développement logiciel agile peuvent aussi utiliser Wrike pour prioriser les tâches en backlog de produits, gérer les sprints et organiser des rétrospectives.

Vous voulez assurez la réussite de vos futurs projets ? Profitez du potentiel de la méthodologie agile avec le modèle personnalisable de Wrike.