Comment rédiger une bonne User Story ?

Comment rédiger une bonne User Story ?

Tout projet (qu’il s’agisse d’un nouveau logiciel ou d’un nouveau bâtiment) nécessite une documentation. Avant qu’une équipe de spécialistes puisse commencer à donner vie à la vision d’un client, elle doit comprendre dans toute la mesure du possible toutes les exigences fonctionnelles et non fonctionnelles du produit qu’elle s’apprête à construire.

La plupart des difficultés rencontrées lors de la rédaction des exigences d’un projet surviennent lorsque le client ne partage pas des détails suffisamment clairs pour rendre compte de ce qui est construit ou de la raison pour laquelle le projet est entrepris, tout en fournissant suffisamment de détails pour que l’équipe puisse comprendre les caractéristiques du produit.

Que sont les User Stories Agiles ?

Qu’est-ce qu’une User Story ? Les histoires d’utilisateur en termes d’exigences de produit, et, en particulier, pour les exigences logicielles sont devenues très populaires comme un moyen simple d’articuler le besoin de l’entreprise et de décrire la fonctionnalité souhaitée.

L’idée derrière une histoire d’utilisateur est très simple, mais elle peut aussi être trompeuse. Afin d’apprendre à rédiger de bonnes histoires d’utilisateur qui soient utiles à l’entreprise et à l’équipe de développement, nous pouvons commencer par définir ce qu’une histoire d’utilisateur n’est pas :

  • Ce n’est pas une description de fonctionnalité.
  • Ce n’est pas une exigence non fonctionnelle distincte.
  • Ce n’est pas une vague idée d’une fonctionnalité qu’il serait bon de réaliser un jour.

Si nous nous souvenons de ces limites, nous découvrirons qu’à la base, chaque histoire d’utilisateur en Agile est l’unité minimale de travail sur laquelle les équipes doivent se concentrer, car chaque histoire d’utilisateur se concentre sur le résultat souhaité pour l’utilisateur final. Les histoires d’utilisateur elles-mêmes sont souvent appelées histoires d’utilisateur agiles, afin de comprendre qu’elles font partie intégrante de divers cadres agiles.

Pourquoi la rédaction des user stories, leur affinement et leur hiérarchisation s’intègrent-ils si bien dans les différents cadres et méthodologies Agile ?

Il y a plusieurs raisons à cela.

Tout d’abord, les user stories ne sont par définition pas finies dans leur forme, elles invitent à la discussion ouverte et nécessitent une détalonnage, ce qui renforce l’esprit de collaboration requis par Agile.

Deuxièmement, les user stories fournissent un contexte qui aide les développeurs à comprendre plus clairement les besoins de l’entreprise. Ils peuvent alors travailler sur le logiciel en gardant ces besoins à l’esprit.

Pourquoi créer des User Stories ?

Les user stories fournissent un langage commun à l’équipe

L’utilisation des user stories comme base des exigences logicielles aide tous les membres de l’équipe de développement à être sur la même longueur d’onde, en s’assurant que chaque membre de l’équipe est conscient de l’objectif de son travail.

Les user stories augmentent la collaboration au sein de l’équipe

Les histoires d’utilisateurs donnent à l’équipe des raisons supplémentaires de poser des questions ouvertes au propriétaire du produit, ce qui incite à une enquête plus approfondie sur les besoins des utilisateurs et les objectifs commerciaux du produit. Pour cette raison, les équipes qui s’appuient sur les user stories dans leur planification ont tendance à être plus efficaces dans l’estimation des tâches, tant en termes de complexité technique que de temps nécessaire à leur mise en œuvre.

Les user stories sont également bénéfiques pour différentes équipes, que leur cadre préféré soit Scrum ou Kanban ou un mélange des deux

Les user stories sont également bénéfiques pour les cadres de gestion de projet plus inclusifs, puisque le raffinement des user stories peut également s’étendre à la gestion des risques.

Les user stories motivent les membres non techniques de l’équipe à participer plus activement

De nombreux apports précieux peuvent être perdus, en particulier si une personne qui a une perspective unique du côté de l’entreprise est trop timide ou se décourage de parler lorsqu’elle est intimidée par la présence de membres de l’équipe plus compétents sur le plan technique. Comme les user stories ne sont pas rédigées dans un langage technique, leur utilisation crée une atmosphère plus égale et plus accueillante au sein de l’équipe.

Les user stories facilitent le développement logique, itératif et progressif du produit

Les histoires d’utilisateurs peuvent être combinées en de plus grandes pièces de travail (épopées) pour former une image plus large, ce qui aide l’équipe de projet à saisir l’idée derrière le produit dans son ensemble et à la garder à l’esprit tout en travaillant sur des détails plus petits.

Comment écrire des User Stories

Comment rédiger une bonne User Story ?

Pour vous assurer que votre user story est aussi utile que possible, vous devez suivre plusieurs bonnes pratiques :

Gardez à l’esprit les rôles des utilisateurs.

Traditionnellement, chaque user story comprend la mention d’un rôle d’utilisateur. De cette façon, dès le début, tous les membres de l’équipe de développement sont obligés de se concentrer sur les rôles et les autorisations et sur ce que chaque type d’utilisateur veut accomplir avec l’aide du produit.

Définissez clairement la « définition de ce qui est fait » et les critères d’acceptation.

Lorsqu’il travaille sur une histoire d’utilisateur, le développeur doit avoir une idée claire du moment où il peut considérer son travail comme terminé. La « définition de l’achèvement » est un ensemble de critères qui sert cet objectif et que l’équipe s’accorde à utiliser pour un projet particulier.

La définition de l’achèvement est souvent confondue avec les critères d’acceptation. La différence ici est que la définition de ce qui est fait est appliquée à un niveau plus élevé et est la même pour toutes les user stories d’un projet, alors que les critères d’acceptation décrivent des caractéristiques spécifiques applicables à une user story particulière.

Définir quand une user story est complète et prête aidera l’équipe à planifier son travail et rendra les tests des nouvelles fonctionnalités plus faciles et plus efficaces.

Définissez les sous-tâches qui peuvent être réalisées dans le cadre d’une user story.

Rien ne vous empêche de diviser une user story en plusieurs sous-tâches, afin de faciliter le travail de l’équipe de développement :

  • Valider les besoins de l’utilisateur
  • Créer des épopées
  • Se concentrer sur les types d’utilisateurs

User stories INVEST

Les informaticiens ont souvent recours à des abréviations pour mémoriser quelque chose d’important de manière simple et amusante. L’une de ces abréviations – « invest » – a été conçue spécifiquement pour décrire six caractéristiques essentielles que les user stories doivent avoir pour être les plus utiles.

Que signifie exactement INVEST ? Une bonne user story doit être :

  • « I » – indépendante. Cela signifie que l’équipe peut travailler à la mise en œuvre des user stories dans l’ordre qu’elle souhaite, et comme les stories ne dépendent pas les unes des autres, l’équipe ne se bloquera pas mutuellement.
  • « N » – Négociable. Comme nous l’avons mentionné ci-dessus, les bonnes user stories sont le résultat direct de la collaboration de l’équipe et naissent d’une discussion ouverte qui va au-delà d’un flux de travail prédéfini
  • « V » – Valable. Cette caractéristique fait référence au fait que chaque user story – une fois mise en œuvre – apporte une valeur supplémentaire aux utilisateurs.
  • « E » – Estimable. Une équipe devrait être en mesure de discuter et de définir le temps qu’il lui faudra pour mettre en œuvre une user story particulière.
  • « S » – Petit. Une user story peut être décomposée en plusieurs tâches, mais elle est essentiellement de bas niveau et peut être traitée en une seule itération (sprint). Chaque user story peut être travaillée par une équipe différente et à la fin de cette itération, elle sera entièrement terminée.
  • « T » – Testable. Les bonnes user stories sont faciles à tester car elles ont des critères d’acceptation clairement définis. Cela permet à l’assurance qualité de s’assurer que l’histoire est mise en œuvre conformément à sa description. Les critères d’acceptation des user stories sont essentiels pour s’assurer que la valeur métier sera fournie et que l’équipe sera sur la même longueur d’onde que le propriétaire du produit.

Outils pour la visualisation des user stories

Quels outils pourraient être utilisés pour la visualisation des User Stories ?

De nombreux cadres et approches Agile préconisent la visualisation du flux de travail, afin que tous les membres de l’équipe soient sur la même longueur d’onde et que la progression soit facilement suivie. Étant donné que les équipes Agile de développement logiciel sont souvent partiellement ou totalement distribuées, l’utilisation d’un tableau traditionnel avec des notes autocollantes n’est pas vraiment une option viable. Cependant, de nombreuses entreprises ont créé leurs propres outils pour visualiser les histoires d’utilisateurs et leur cycle de vie dans un projet.

Voici quelques-uns des outils que vous pouvez utiliser pour visualiser et cartographier les histoires d’utilisateurs :

  • Trello est connu pour ses images et dispose de listes d’utilisateurs et de toutes les fonctionnalités essentielles requises pour la cartographie des histoires. Il permet les commentaires et les discussions en temps réel pour l’équipe. La direction peut organiser le backlog en ajoutant des dates d’échéance, en créant des listes de contrôle, des étiquettes, et il est même connecté à Google Drive, Dropbox et OneDrive pour télécharger des fichiers.
  • FeatureMap fournit un tableau numérique où votre équipe peut partager des mises à jour en temps réel. Les propriétaires de produits aiment utiliser cet outil car il leur permet de visualiser l’ensemble du projet et de hiérarchiser les tâches au sein de celui-ci. FeatureMap s’intègre à Jira et à Trello.
  • Craft est un autre outil puissant apprécié par les équipes Agile pour sa flexibilité. Il permet de relier des histoires et des sous-récits, et de collaborer en temps réel entre les équipes.
  • Storiesonboard.com est un autre outil de story mapping. Avec StoriesOnBoard, les utilisateurs peuvent hiérarchiser les aspects les plus urgents du projet. StoriesOnBoard offre un espace de stockage illimité et possède une interface conviviale très claire. Il est également gratuit.
  • Mural est un outil qui permet de visualiser le travail avec des notes autocollantes. Il est souvent considéré comme un excellent choix pour les équipes à distance, et est très axé sur le design. Mural fournit une grande variété de modèles qui peuvent être utilisés à des fins diverses, y compris le story mapping.

Commentaires de l'article