User stories avec des exemples et un modèle

Résumé : une user story est une explication non formelle, générale d'une fonctionnalité logicielle écrite du point de vue de l'utilisateur final. Son but est d'expliquer comment une fonctionnalité logicielle apportera de la valeur au client.

Il est tentant de croire que les user stories sont, en termes simples, des exigences système du logiciel. Mais ce n'est pas le cas.

Donner la priorité aux personnes est une valeur clé du développement Agile, et une user story met les utilisateurs finaux au centre de la discussion. Les stories utilisent un langage non technique pour fournir un contexte à l'équipe de développement et à ses efforts. Après avoir lu une user story, l'équipe sait pourquoi elle développe ce qu'elle développe, et quelle valeur elle crée.

Les user stories sont l'un des éléments essentiels d'un programme Agile. Elles contribuent à fournir un framework axé sur les utilisateurs pour le travail quotidien, ce qui favorise la collaboration, la créativité et la conception d'un meilleur produit dans l'ensemble.

Dans un framework Agile, les user stories constituent les unités de travail les plus petites. Elles représentent un objectif final (pas une fonctionnalité) exprimé du point de vue de l'utilisateur du logiciel.

Une user story est une explication non formelle, générale d'une fonctionnalité logicielle écrite du point de vue de l'utilisateur final.

L'objectif d'une user story est de définir comment un travail apportera une certaine valeur ajoutée au client. Remarque : les « clients » ne doivent pas forcément être des utilisateurs externes au sens traditionnel. Il peut s'agir de clients en interne ou de collègues qui, au sein de votre organisation, dépendent de votre équipe.

Les user stories désignent une série de phrases, rédigées dans un langage simple, qui décrivent le résultat souhaité. Elles n'entrent pas dans le détail. Des exigences sont ajoutées par la suite, une fois convenues par l'équipe.

Les stories s'intègrent parfaitement aux frameworks Agile comme Scrum et Kanban. Dans Scrum, les user stories sont ajoutées aux sprints et sont « utilisées » durant celui-ci. Les équipes Kanban font un pull des user stories dans leur backlog, puis les exécutent via leur workflow. C'est ce travail sur les user stories qui aide les équipes Scrum à s'améliorer dans l'estimation et la planification du sprint, augmentant la précision des prévisions et l'agilité. Grâce aux stories, les équipes Kanban découvrent comment gérer le travail en cours (WIP) et améliorer davantage leurs workflows.

Les user stories sont également des éléments constitutifs de plus grands frameworks Agile, comme les epics et les initiatives. Les epics sont d'importantes tâches décomposées en un ensemble de stories, et plusieurs epics forment une initiative. Ces structures plus vastes garantissent que le travail quotidien de l'équipe de développement (en cours) contribue aux objectifs organisationnels intégrés dans des epics et des initiatives.

En savoir plus sur les epics et les initiatives

Les équipes de développement qui débutent avec Agile considèrent parfois les user stories comme une étape supplémentaire. Pourquoi ne pas simplement subdiviser un grand projet (l'epic) en une série d'étapes et se mettre au travail ? Les stories fournissent cependant un contexte important à l'équipe et associent des tâches à la valeur qu'elles procurent.

Les user stories apportent un certain nombre d'avantages clés :

• Les stories gardent l'accent sur l'utilisateur. Grâce à la liste de tâches à faire, l'équipe reste concentrée sur le travail à réaliser. Cependant, avec un ensemble de stories, elle se concentre sur la résolution des problèmes rencontrés par les véritables utilisateurs.
  
• Les stories facilitent la collaboration. Une fois l'objectif final défini, l'équipe peut collaborer pour décider comment répondre au mieux aux besoins des utilisateurs et atteindre cet objectif.
  
• Les stories favorisent des solutions créatives. Les stories encouragent l'équipe à adopter une réflexion critique et créative afin de trouver comment atteindre au mieux un objectif final.
  
• Les stories créent une dynamique. Chaque story implique de petits défis à relever et de petites victoires pour l'équipe de développement, ce qui crée une dynamique.

See how user stories work in Jira

Une fois la story écrite, le moment est venu de l'intégrer à votre workflow. Généralement, la story est rédigée par le Product Owner, le responsable produit ou le responsable de programme avant d'être soumise pour revue.

Durant une réunion de planification de sprint ou d'itération, l'équipe détermine les stories sur lesquelles elle va se pencher pour ce sprint. Elle évoque les exigences et fonctionnalités que requiert chaque user story. C'est l'occasion d'aborder les aspects techniques et créatifs dans l'implémentation de la story par l'équipe. Une fois un consensus atteint, ces exigences sont ajoutées à la story.

Autre étape courante de cette réunion : noter les stories en fonction de leur complexité ou de leur durée d'exécution. Les équipes utilisent des tailles de T-shirt, la suite de Fibonacci ou le Planning Poker pour effectuer des estimations correctes. Une story devrait être dimensionnée de sorte à s'achever en un sprint. Ainsi, lorsque l'équipe spécifie chaque story, elle s'assure de subdiviser les stories qui iront au-delà de l'horizon d'achèvement.

Tenez compte des points suivants lorsque vous rédigez des user stories :

• Définition de « Terminé » : la story est généralement « terminée » lorsque l'utilisateur peut achever la tâche décrite. Cependant, veillez à définir ce concept.
  
• Définissez des tâches ou des sous-tâches : déterminez quelles étapes spécifiques doivent être effectuées et qui est responsable de chacune d'elles.
  
• Personas utilisateur : pour qui ? Si vous avez plusieurs utilisateurs finaux, envisagez de créer plusieurs stories.
  
• Étapes organisées : rédigez une story pour chaque étape d'un processus plus vaste.
  
• Écoutez le feedback : échangez avec vos utilisateurs, et cernez le problème ou le besoin. Inutile de deviner une story si vous pouvez l'obtenir directement de vos clients.
  
• Durée : la durée reste un sujet sensible. De nombreuses équipes de développement évitent de discuter de la durée, et s'appuient plutôt sur leurs frameworks d'estimation. Comme les stories doivent pouvoir être terminées en un seul sprint, les stories qui pourraient nécessiter des semaines ou des mois doivent être divisées en stories plus petites ou être considérées comme leur propre epic.
  

Une fois les user stories clairement définies, assurez-vous qu'elles sont visibles de toute l'équipe.

Les users stories sont souvent exprimées en une phrase simple, structurée comme suit :

« En tant que [persona], je [souhaite que] [afin de] ».

Voyons maintenant ce que signifie chaque élément :

• « En tant que [persona] » : pour qui développons-nous cette fonctionnalité ? Nous ne cherchons pas seulement l'intitulé d'une fonction, mais aussi le persona de cette personne. Max. Notre équipe devrait avoir une compréhension commune de l'identité de Max. Il faut espérer que nous nous sommes entretenus avec beaucoup de « Max ». Nous comprenons comment cette personne travaille, comment elle pense et ce qu'elle ressent. Nous avons de l'empathie pour elle.
• « Souhaite que » : c'est ici que nous décrivons l'intention de Max, et non les fonctionnalités qu'il utilise. Qu'essaie-t-il de faire réellement ? Cet énoncé ne devrait pas impliquer d'implémentation. Si vous décrivez une composante de l'interface utilisateur et non l'objectif de l'utilisateur, vous êtes hors sujet.
• « Afin de » : comment son désir immédiat de faire quelque chose s'intègre-t-il à la vue d'ensemble ? Quel avantage global cette personne essaie-t-elle d'obtenir ? Quel est le principal problème à résoudre ?

Par exemple, les user stories pourraient ressembler à ce qui suit :

• En tant que Max, je souhaite inviter mes amis afin de pouvoir profiter de ce service ensemble.
• En tant que Sasha, je souhaite organiser mon travail afin d'avoir la sensation de mieux maîtriser les choses.
• En tant que responsable, je souhaite être en mesure de comprendre l'avancement de mes collègues afin de pouvoir mieux parler de nos réussites et de nos échecs.

Cette structure n'est pas obligatoire, mais elle est utile pour définir l'état « Terminé ». Lorsque ce persona peut capturer la valeur souhaitée, la story est terminée. Nous encourageons les équipes à définir leur propre structure et à s'y conformer.

Les user stories décrivent la cause et l'objet du travail quotidien des membres de l'équipe de développement. Elles sont souvent exprimées sous la forme persona + besoin + finalité. Pour assurer un processus transparent, il est essentiel de comprendre leur rôle en tant que source de référence pour les livrables de l'équipe, mais aussi leur raison d'être.

Commencez par évaluer le prochain, ou plus urgent, projet d'envergure (par exemple, une epic). Subdivisez-le en plus petites user stories et travaillez avec l'équipe de développement pour affiner son contenu. Dès que vos stories sont publiées et accessibles à l'ensemble de l'équipe, vous pouvez vous mettre au travail.