Maîtrisez les User Stories : Le Guide Ultime avec des Exemples Concrets pour Révolutionner Votre Approche

La manière traditionnelle de concevoir les exigences de projet/produit consiste à réfléchir aux besoins du client, puis à détailler le tout à des niveaux très fins en créant un document de Scope pour la solution. Cette approche n’est pas adaptée lorsque nous voulons découvrir de manière progressive les exigences du client/utilisateur. Les User Stories nous aident à explorer les exigences des utilisateurs de manière progressive. La User Story est une façon simple de parler de petites portions des exigences de l’utilisateur pour le produit.

Prenons un produit hypothétique, appelé wowhotelsdotcom. Le but de ce site web est d’aider à trouver les meilleures options d’hébergement en termes de rapport qualité-prix. Après une recherche initiale, les parties prenantes du site ont convenu de se concentrer sur les types d’utilisateurs suivants. Ces types d’utilisateurs sont des exemples. Avant d’explorer les User Stories pour le produit, identifions d’abord les utilisateurs et clarifions ce qu’ils veulent faire avec le produit.

• Voyageur Solo

  • Recherche de bas prix, prêt à aller dans des endroits éloignés pour économiser de l’argent.
  • Ne cherche que quelques installations récréatives à l’intérieur de l’hôtel.
  • Ne prend généralement pas le déjeuner et le dîner à l’hôtel, sort de la chambre et revient le soir avec un sac de nourriture et de boissons.
  • Durée de séjour habituelle : deux jours.

• Voyageur en Groupe

  • Recherche de bas prix et d’espace pour des activités de groupe.
  • Veut un hôtel près des attractions de la ville.
  • Recherche des installations récréatives à l’intérieur de l’hôtel.
  • Prend généralement le dîner à l’hôtel, donc recherche de bonnes options alimentaires.
  • Durée de séjour habituelle : une semaine.

• Gérant d’Hôtel

  • Responsable de la rentabilité de l’hôtel.

Nous soutenons les voyages aux meilleurs prix et la flexibilité pour choisir ce qui convient le mieux à chacun. Nous le faisons en rendant notre site web super simple et rapide. Après avoir identifié la vision de la solution et les utilisateurs cibles, la prochaine étape consiste à explorer les besoins des utilisateurs.

Une User Story décrit une exigence et une fonctionnalité qui seront précieuses pour un utilisateur ou un acheteur d’un système ou d’un logiciel. Les User Stories ont trois aspects :

1. Description écrite pour la planification et en tant que rappel.
2. Conversations sur la story qui se déroulent au bon moment pour découvrir les détails de user story.
3. Critères de Vérification (Tests) qui communiquent et documentent les détails et servent également à déterminer l’achèvement de la story.

Ron Jeffries a nommé ces trois aspects Carte, Conversation et Confirmation.

La Carte donne une vue concrète d’une User Story, mais ne doit pas être assimilée à de la documentation ; la Carte contient la description d’une User Story, mais les détails sont élaborés dans la Conversation et finalement enregistrés pour la vérification dans la Confirmation.

Comme exemple de User Story, voyons la Carte 1.1, une carte de wowhotelsdotcom. En tant que Voyageur Solo, je veux trouver des détails sur l’hôtel afin de pouvoir sélectionner le bon hôtel pour moi.

User Story 

Généralement, nous écrivons la User Story avec la structure suivante :

• En tant que < utilisateur/role utilisateur/type d’utilisateur/persona utilisateur >
• Je veux < faire une activité/action avec le système >
• Afin que < je satisfasse mon exigence >

Quelques autres User Stories pourraient être :

• 1.2 : En tant que Voyageur Solo, je veux connaître les meilleurs prix disponibles pour le mois entier pour l’hôtel sélectionné afin de choisir les dates d’arrivée et de départ en conséquence.
• 1.3 : En tant que Voyageur Solo, je veux connaître les tarifs des hôtels à proximité afin de trouver le meilleur rapport qualité-prix pour moi.
• 1.4 : En tant que Voyageur Solo, je veux connaître le menu alimentaire de l’hôtel afin de le prendre en compte lors de la sélection de l’hôtel.
• 1.5 : En tant que Voyageur Solo Femme, je veux connaître les équipements disponibles dans la chambre afin de les prendre en compte lors de la sélection de l’hôtel.
• 1.6 : En tant que Voyageur en Groupe, je veux connaître la distance entre l’hôtel et les points de transport en commun afin de prendre en compte lors de la sélection de l’hôtel.
• 1.7 : En tant que Voyageur en Groupe, je veux connaître l’option de prix pour la chambre et les repas afin que je puisse prendre en compte lors de la sélection de l’hôtel.

Où sont les détails ?

Quand l’équipe de développement lit la carte 1.1, obtient-elle les détails nécessaires pour créer la fonctionnalité ? Par exemple, l’équipe de développement sait-elle quels détails partager pour satisfaire le besoin du voyageur solo de trouver le bon hôtel ? Les détails émergeront suite à la Conversation. Les Conversations entre l’équipe de développement, le product owner, les scrum master et les parties prenantes se déroulent dans le cadre de l’activité de raffinement du backlog.

Lors du raffinement du backlog :

• Discuter des User Stories qui sont censées être développées bientôt, car les stories doivent être affinées au bon moment.
• Si l’équipe réalise que cette story est trop grande pour tenir dans un sprint/itération, alors cette user story doit être divisée en user stories plus petites (appelées Epic dans le jargon agile).
• Si la story est de la bonne taille, assez petite pour rentrer dans l’itération/sprint et qu’elle est censée être développée bientôt, l’équipe de développement discutera des détails avec les parties prenantes, Scrum Master et PO et prendra des notes.
• Les détails sont enregistrés sous la forme de critères de validation vérifiables appelés critères d’acceptation, également connus sous le nom de Confirmation.

Carte 1.1

En tant que Voyageur Solo, je veux trouver des détails sur l’hôtel afin de pouvoir sélectionner le bon hôtel pour moi.

Cela semble trop grand pour être développé en un seul sprint/itération. Pour détailler cette User Story, ils ont collaboré avec le product owner et l’ont divisée en User Stories suivantes.

Carte 1.1.1

En tant que Voyageur Solo, je veux trouver des détails sur les installations récréatives afin de pouvoir sélectionner le bon hôtel pour moi.

Carte 1.1.2

En tant que Voyageur Solo, je veux trouver des détails sur les zones à proximité afin de pouvoir sélectionner le bon hôtel pour moi.

Carte 1.1.3

En tant que Voyageur Solo, je veux voir des photographies des installations afin de pouvoir sélectionner le bon hôtel pour moi.

Carte 1.1.4

En tant que Voyageur Solo, je veux lire des avis postés afin de pouvoir sélectionner le bon hôtel pour moi.

Toutes les petites user stories doivent être aussi indépendantes que possible pour offrir une petite portion de valeur à l’utilisateur.

Plongeons dans la Conversation avec le Product owner pour la User Story Carte 1.1.1.

Carte 1.1.1

En tant que Voyageur Solo, je veux trouver des détails sur les installations récréatives afin de pouvoir sélectionner le bon hôtel pour moi.

• Équipe de Développement: Quelles installations récréatives souhaitez-vous connaître ?
• Product owner: J’ai vu des voyageurs intéressés par les piscines, les centres de remise en forme et les restaurants.
• Équipe de Développement: Que faut-il pour les informations sur la piscine ?
• Product owner: Juste Oui ou Non est suffisant.
• Équipe de Développement: Et pour les autres installations ?
• Product owner: Juste Oui / Non pour toutes.

Enregistrement des Tests de Confirmation

Une fois la Conversation terminée, l’équipe de développement, le scrum master et le product owner collaborent pour résumer les points de test de vérification. Voici des Confirmations possibles.

• Vérifier que les détails de la piscine sont affichés au format Oui/Non.
• Vérifier que les détails du centre de remise en forme sont affichés au format Oui/Non.
• Vérifier que les détails du restaurant sont affichés au format Oui/Non.
• Vérifier que l’aspect visuel reste cohérent avec la page actuelle.
• Vérifier que les informations sont présentées sous forme de tableau pour être vues en une seule fois.

Bill Wake a proposé l’acronyme INVEST pour donner des caractéristiques aux bonnes User Stories : Indépendantes, Négociables, Valuables, Estimables, Petites et Testables.

• Indépendantes : Les user stories liées à d’autres créent des défis de planification et d’estimation. Nous devrions éviter autant que possible d’introduire des dépendances entre les stories.

• Négociables : Les stories sont succinctes, et les détails sont explorés progressivement dans la conversation. Les stories ne sont pas des exigences écrites, ce sont des outils pour découvrir progressivement et collaborativement les exigences. Cela signifie qu’à tout moment, l’équipe de développement et le product owner peuvent renégocier la story, tant que les deux parties sont d’accord.

• Valuables : Comme les stories sont explorées du point de vue de l’utilisateur, une story devrait apporter de la valeur à l’utilisateur. La valeur peut être un avantage, la réduction des risques ou l’acquisition de connaissances, ou tout ce que l’utilisateur considère comme une valeur.

• Estimables : L’équipe de développement devrait pouvoir estimer l’User Story. l’une des principales raisons est de s’assurer que l’histoire est assez petite pour tenir dans un sprint/itération donné.

• Petites : L’un des objectifs de la User Story est de favoriser le développement en petits lots. Si une exigence prend beaucoup de temps à développer, les retours sur la mise en œuvre sont également retardés. En méthodes agiles, nous voulons obtenir un logiciel fonctionnel rapidement pour réduire les risques. Les stories doivent donc être assez petites pour tenir dans un Sprint/Itération de l’équipe de développement.

• Testables : Les user stories doivent être testables pour aider à déterminer leurs détails et leur exhaustivité. Une story devrait avoir des critères d’acceptation / critères de confirmation ajoutés au fur et à mesure de son détail. Plus les critères d’acceptation sont objectifs, plus il est facile de communiquer les détails et de vérifier l’exhaustivité.

Conclusion :

Les user stories nous aident à découvrir et valider de manière collaborative et progressive les exigences. La carte, la conversation et la confirmation aident à ajouter des détails juste à temps. Les user stories ne doivent pas être comprises comme une autre façon de documenter les exigences, elles doivent être comprises comme un moyen de fournir de la valeur de manière progressive.

Pourquoi choisir la formation en ligne chez CertiSkills ?

CertiSkills est un organisme de formation en digital learning. Nous vous préparons aux certifications les plus reconnues sur le marché, telles que PMI, AXELOS, IASSC, PEOPLECERT, dans des domaines tels que l’informatique, l’agilité, Scrum, Prince2, la gestion de projet, et bien plus encore.

Avec CertiSkills, vous pouvez apprendre quand vous le souhaitez, où vous le souhaitez, 24 heures sur 24, 7 jours sur 7, 365 jours par an, à votre propre rythme.

N’attendez plus, réservez votre formation 100% en ligne immédiatement ou contactez-nous au (+33) 6-29-37-62-76 ou sur contact@certiskills.fr.