User stories avec exemples et modèle

Les user stories sont des tâches de développement souvent exprimées sous la forme suivante : « persona + besoin + finalité ». 

Max Rehkopf Max Rehkopf
Parcourir les rubriques

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 les user stories mettent véritablement 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.

Que sont les user stories Agile ?

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.

L'objectif d'une user story est de définir comment un travail apportera une certaine valeur ajoutée au client. Attention, 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

Epics, stories et thèmes Agile | Atlassian – Le coach Agile

Pourquoi créer des user stories ?

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 de la dynamique. Chaque story implique de petits défis à relever et de petites victoires pour l'équipe de développement, ce qui crée de la dynamique. 

Fonctionnement des user stories

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. 

Comment rédiger des user stories ?

Pensez aux 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 les commentaires : é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.
     
  • Temps : un sujet délicat. Beaucoup d'équipes de développement évitent toute discussion sur le temps et se basent plutôt sur leurs frameworks d'estimation. Puisque les stories devraient pouvoir être achevées en un sprint, celles susceptibles de prendre plusieurs semaines voire plusieurs mois devraient être subdivisées en plus petits éléments ou faire l'objet de leur propre epic.
     

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

Modèle et exemples d'user stories

 Les user 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 est l'avantage global qu'il essaie 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 Sascha, 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 complète. Nous encourageons les équipes à définir leur propre structure et à s'y conformer.

Premiers pas avec les user stories Agile

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.

suivant
Estimation