Connaître les besoins réels des utilisateurs et développer des fonctionnalités cohérentes avec cette réalité sont des facteurs clés pour construire des produits performants. Dans cet article, vous verrez plus de détails sur ce sujet, notamment en ce qui concerne les techniques d’écriture de user stories de qualité et assertives, l’exemple d’application et d’autres sujets, qui sont également abordés dans le livre Product Backlog Building (PBB), par les auteurs Fábio Aguiar et Paulo Caroli.
- Émergence des User Stories
- Méthode en Cascade et Méthodes Agiles
- Formats des User Stories d’Utilisateurs
- Critères d’Acceptation
- Décomposer les User Stories en Tâches
- Interface Utilisateur
- Écrire des User Story Avec PBB
- Exemple de User Story
- TAPA pour Vérifier la Qualité des User Stories
- Animateurs chez PBB
- Définition de Préparé
- Définition de Fait
- User Story d’Utilisateurs dans Scrum
- User Strory d’Utilisateurs dans Kanban
Émergence des User Stories
Lorsque nous parlons de user stories, nous ne pouvons pas oublier un nom important : l’auteur Mike Cohn. Il est considéré comme l’une des grandes références en matière de user stories.
Dans son livre User Stories Applied: For Agile Software Development, Mike Cohn souligne que la meilleure façon de créer un produit conforme aux besoins des utilisateurs est d’utiliser des user stories.
C’est lui qui a popularisé l’acronyme INVEST, que vous verrez plus en détail ci-dessous. Pour Cohn, il est essentiel d’identifier les rôles de chaque utilisateur, car, à partir de là, il existe un lien avec la douleur de cet utilisateur et, par conséquent, la création de produits de valeur.
Méthode en Cascade et Méthodes Agiles
La Waterfall Method, également appelée Waterfall Model ou Traditional Method, est un modèle de gestion basé sur des phases, où la fin d’une phase indique le début de la suivante. Par exemple : planification, exécution, validation et livraison.
Cependant, pour l’heure actuelle, malgré le succès du siècle dernier, le modèle Cascade apparaît comme un modèle « cast », considérant qu’il n’y a d’avancée dans le projet qu’à partir de la fin de chaque étape et que ce suivi dépend encore de , à partir de l’approbation de l’artefact généré à cette étape.
Les méthodes agiles sont venues changer cette réalité. Avec un modèle beaucoup plus flexible, il s’appuie sur l’équipe travaillant en cycles courts et fréquents, avec une planification des activités et des livraisons rapides et centrées sur l’utilisateur. Une autre grande différence réside dans le fait que des modifications peuvent être apportées tout au long du développement du produit, alors que dans la méthode en cascade, les modifications ne sont pas les bienvenues.
Formats des Uuser Stories
À l’origine, les user stories d’utilisateurs sont nées dans le but que la personne concernée écrive. Cependant, au fil du temps, en grande partie grâce à l’expansion du framework Scrum, le Product Owner est devenu la principale personne écrivant ces user stories et les organisant dans un backlog de produit. Cependant, n’importe qui peut (et devrait) écrire une user story. Au fait, PBB vous aide à écrire des user stories. Découvrez-en plus dans cet article et dans le livre PBB.
3W de User Story
User Story est un format textuel pour la description concise d’une exigence, qui cherche à répondre à trois questions spécifiques de l’acronyme connu sous le nom de 3W : Qui ? Quoi ? Pourquoi ?
INVEST
Dans son livre Extreme Programming Explored, William C. Wake a partagé l’acronyme INVEST, où chaque lettre représente l’une des six caractéristiques importantes d’une user story : indépendante, négociable, précieuse, estimable, petite et testable.
Quelques années après cette création, Mike Cohn a fini par renommer la lettre S, de petite, à convenablement dimensionnée, car certaines personnes ont créé des user stories un peu plus grandes, mais adaptées à leur contexte.
- INDÉPENDANT : Une user story ne dépend pas d’une autre.
- NÉGOCIABLE : Une user story capture l’essence de ce qui est désiré. Ce n’est pas un contrat fermé, les conversations et les négociations sont les bienvenues.
- VALEUR : Une user story décrit clairement la valeur client.
- ESTIMABLE : Une user story fournit suffisamment d’informations pour que l’équipe puisse proposer une estimation de haut niveau.
- SUR MESURE : Une bonne user story doit être de taille relativement petite pour être achevée dans les plus brefs délais et s’intégrer dans une itération en fonction du contexte de l’équipe.
- TESTABLE : une user story doit être suffisamment claire pour que des tests puissent être définis pour elle.
Dès lors, l’acronyme INVEST aide à écrire de bonnes user story, avec les questions suivantes : est-elle Indépendante ? Négociable? Valable pour l’entreprise ? Estimable? Sous mesure ? Testable?
Modèle 3C
En plus du modèle INVEST, une bonne user story se compose également de trois éléments, appelés les 3C :
CARTE : La description faite pour la user story doit tenir sur une fiche, avec des informations brèves et suffisantes pour l’identifier. Le format le plus courant est :
- AS <rôle/profil>
- CAN <action/objectif>
- POUR <avantage/raison>
CONVERSATION : Pour clarifier les doutes et détailler le travail de mise en œuvre, de nombreuses conversations sont nécessaires. Dans les user stories, les conversations seront continues, pas seulement au début lorsque l’exigence est définie. Les meilleurs documents nous aident à nous souvenir de nos conversations, mais ils ne les remplacent pas.
CONFIRMATION : dans cette étape, il est déterminé si l’objectif de la user story a été atteint. Pour cela, les critères d’acceptation sont importants et doivent être définis pour chaque histoire avant que l’équipe ne commence à la mettre en œuvre.
Critères d’Acceptation
Les critères d’acceptation sont destinés à décrire comment valider une user story. Généralement, une histoire aura des critères d’acceptation, également appelés AC (critères d’acceptation).
Ce faisant, les AC fournissent une liste de contrôle qui détermine quand une user story est complète, complète et fonctionnelle.
Du livre Product Backlog Building, nous prenons comme exemple l’histoire suivante : « En tant que client, j’aimerais retirer de l’argent au guichet automatique pour éviter la ligne bancaire ». Voici une liste possible d’AC pour cette situation :
- Le client disposant d’un solde suffisant peut retirer de l’argent de son compte.
- Le client sans solde suffisant n’est pas en mesure de retirer de l’argent de son compte.
- Le client avec un solde suffisant ne peut pas retirer de l’argent de son compte si le guichet automatique n’a pas assez d’argent pour retirer.
Le format présenté est comparé à une liste de contrôle utilisée pour vérifier que l’histoire est complète et fonctionne, c’est-à-dire si elle passe par tous les AC. S’il y a plus de cinq critères, il est recommandé de diviser l’histoire en deux.
Décomposer les User Stories en Tâches
Cette décomposition des user stories en plus petits morceaux donne lieu à des tâches. Avec eux, l’équipe de développement entre dans les détails techniques sur la façon dont les plus petits éléments seront implémentés. Contrairement aux user story, les tâches sont plus directes et avec un langage technique, ne suivant pas un format textuel défini.
Les tâches identifient quelque chose qui doit être fait dans une histoire. Comme exemples de tâches, nous avons : modifier les champs dans la table de départ, créer des comptes de test pour les utilisateurs, automatiser les scripts de génération de données, etc.
Interface Utilisateur
La façon de décrire l’interface d’une user story varie selon la décision de l’équipe et cela peut se faire de la manière suivante : croquis (ou simples dessins sur papier), wireframes, maquettes ou prototype.
Une question qui se pose est de savoir quelle partie de l’interface doit être définie pour commencer à travailler sur l’histoire ? La réponse est essentiellement l’accord de l’équipe pour décider si l’histoire est prête du point de vue de l’interface utilisateur. Le plus important est que le groupe soit aligné et à l’aise avec le travail à faire.
Écrire des user story Avec PBB
Filling the Canvas PBB sera un facilitateur lors de l’écriture des user stories. Comme vu précédemment, écrire une user story répond essentiellement à trois questions principales : Qui ? Lequel ? Parce que ?
Dans cette perspective, PBB vient aider à l’écriture de user stories. La méthode a le « qui ? » quel est le personnage; le quoi? » quels sont les PBI (abréviation de Product Backlog Items) ; et le « pourquoi? » qui est dans les avantages de la fonctionnalité.
Exemple de User Story
Dans le livre PBB, les auteurs partagent quelques exemples de user story, comme la création du produit numérique Palestra Coletivas. Créé par la communauté Tá Safo, il a pour objectif de préparer un portefeuille de conférences et d’organiser des événements. Vous trouverez ci-dessous quelques détails sur la description de trois fonctionnalités du produit avec des user stories, des critères d’acceptation, des tâches et une interface :
Persona, Fonctionnalité, User Stories
Voici les trois exemples de fonctionnalités de Palestras Coletivas avec leurs personnages et user stories d’utilisateurs respectifs.
PERSONNAGE : HAUT-PARLEUR
FONCTIONNALITÉ 1 : Publier le travail.
HISTOIRE 1.1 : En tant que conférencier, je peux accéder au bureau pour gérer en privé.
HISTOIRE 1.2 : En tant que conférencier, je peux publier des travaux pour rendre le contenu disponible.
HISTOIRE 1.3 : En tant qu’orateur, je peux lier la présentation externe pour intégrer des œuvres.
PERSONNE : PARTICIPANT
FONCTIONNALITÉ 2 : Participer à l’événement.
HISTOIRE 2.1 : En tant que participant, je peux localiser l’événement disponible pour afficher le calendrier.
HISTOIRE 2.2 : En tant que participant, je peux m’inscrire à l’événement pour consommer du contenu.
HISTOIRE 2.3 : En tant que participant, je peux m’inscrire à l’événement pour confirmer ma présence.
PERSONNAGE : ORGANISATEUR
FONCTIONNALITÉ 3 : Organiser un événement.
HISTOIRE 3.1 : En tant qu’organisateur, je peux définir le calendrier des événements pour faire connaître la grille.
HISTOIRE 3.2 : En tant qu’organisateur, je peux faire connaître l’événement dans les médias pour attirer le public.
HISTOIRE 3.3 : En tant qu’organisateur, je peux inviter des co-organisateurs de l’événement pour faciliter l’organisation.
Historique, Critères d’Acceptation, Taches
Maintenant, découvrez un exemple d’une histoire et deux activés à partir de la fonctionnalité « publier le travail » de Palestras Coletivas. L’histoire est conforme à la définition de préparé, avec ses critères d’acceptation, ses tâches et son interface.
HISTOIRE 1.1
En tant qu’orateur, je peux lier la présentation externe pour intégrer des œuvres.
CRITÈRES D’ACCEPTATION 1
SCÉNARIO 1 : Association de présentation sur des plateformes de partage de présentation.
– Étant donné qu’il existe un lien valide sur la plateforme SlideShare
– Quand lier le lien de présentation externe
– Ensuite, il affichera un aperçu de la présentation à l’écran.
CRITÈRES D’ACCEPTATION 2
SCÉNARIO 2 : Associer la présentation au travail d’édition.
– Étant donné que le lien de présentation est valide
– Quand publier le travail
– Ensuite, il affichera la présentation associée dans les détails du travail publié.
TÂCHES
– Consommer le point de terminaison de présentation.
– Créer une interface utilisateur pour afficher le fichier PDF de la présentation.
– Créer une logique backend pour lier la présentation au travail publié.
– Modifier le paramètre en lien public ou privé.
– Créer des données de test pour vérifier que le lien est valide.
– Modifiez la base de données pour inclure le lien de présentation.
TAPA pour Vérifier la Qualité des User Stories
Même en utilisant PBB pour générer vos user story, vous devez vérifier leur qualité, c’est-à-dire l’alignement entre l’équipe sur les principaux attributs de l’histoire. C’est dans cette intention que Manoel Pimentel a créé la technique des TAPAs.
Selon lui, TAPAs permet d’enrichir l’analyse et la compréhension des principaux attributs d’une user story, qui forment l’acronyme TAPA : tangible, atomic, precious, accessible
- TANGIBLE : L’histoire est tactile, concrète et spécifique.
- ATOMIC : L’histoire est petite et indépendante.
- PRECIOUS : L’histoire résout un problème important pour l’utilisateur.
- ACCESSIBLE : L’histoire est claire et facile à comprendre.
Semblable à un repas dans un restaurant de tapas espagnol, Manoel Pimentel explique que vous mangerez plusieurs tapas, qui sont livrées fréquemment (Sprint to Sprint). Contrairement aux restaurants traditionnels (non agiles), qui fonctionnent avec un plat principal qui prendra plus de temps à être servi, et vous aurez probablement besoin d’une fourchette et d’un couteau pour le couper en plus petits morceaux.
Animateurs chez PBB
Dans une séance PBB, il est essentiel de définir qui sera la personne dite facilitatrice. Parmi les missions de l’animateur figurent : aider à décider de la durée de la séance ; adapter la facilitation du PBB en fonction du contexte et de la réalité de l’équipe et de l’organisation ; provoquer la collaboration de toutes les personnes de l’équipe; en plus d’encourager une communication active par tous les participants dans l’idéation, la compréhension, l’analyse et la création d’incréments de produits.
La personne facilitante peut être n’importe qui et n’importe qui ayant un intérêt à aider à construire un bon backlog de produit. Habituellement, quelqu’un de l’équipe assume déjà le rôle d’animateur d’ateliers collaboratifs. Cette personne est un bon candidat pour une première animation PBB. En ce sens, nous avons également plusieurs personnes intéressées par une bonne animation, comme par exemple le Product Owner, le Scrum Master, le coach agile, le chef de produit et le développeur.
Définition de Préparé
La définition de prêt (DoR) est l’accord entre l’équipe et le PO qui indique quand un PBI sera prêt à être intégré dans un Sprint, c’est-à-dire quand il aura suffisamment d’informations pour entrer dans la planification, l’exécution et la livraison.
Les gens disent souvent que : « Cet élément est prêt à commencer le travail », et cela indique généralement que l’équipe :
- Possède les informations nécessaires pour travailler sur l’article ;
- Comprendre le pourquoi de l’article ;
- Peut montrer l’achèvement des travaux ;
- Identifie comment l’élément compose/se rapporte à une fonctionnalité ;
- Convenez que l’élément s’inscrit dans un Sprint.
Pour chaque candidat PBI pour le prochain Sprint, l’équipe vérifie que :
- Le PBI est représenté par une user story.
- PBI est couvert par les critères d’acceptation et BDD.
- PBI est mappé à une interface (si nécessaire).
- Les dépendances PBI sont identifiées (le cas échéant).
Le raffinement du backlog produit doit être continu. Il convient de rappeler que l’utilisation de la définition de préparé et de la définition de terminé ne se limite pas à Scrum, car c’est aussi une pratique très utile lorsque nous travaillons avec Kanban et d’autres méthodes agiles.
Définition de Fait
La définition de done (DoD) est l’accord qui démontre la qualité du PBI produit, dans lequel « done » prouve la satisfaction de chacun avec le travail effectué faisant partie de l’incrément du produit.
Ainsi, par rapport à chaque PBI considéré comme prêt, l’équipe démontre que l’item :
- Fournit un incrément de produit.
- Il envisage les critères d’acceptation établis.
- Il est documenté pour son utilisation.
- Il respecte les normes de codage.
- Maintient les indices de performance des produits.
User Stories d’Utilisateurs dans Scrum
Scrum est considéré comme la méthodologie agile la plus connue et repose sur le concept de Sprint – des cycles courts (une ou deux semaines) – pour maintenir la cadence d’une équipe. Par conséquent, il est recommandé que chaque Sprint commence par une réunion de planification (Sprint Planning) et se termine par une réunion de revue du travail effectué (Sprint Review).
Avant la planification de sprint, les fonctionnalités souhaitées sont détaillées dans les user stories. Pour cette construction, la méthode PBB va permettre de décomposer ces fonctionnalités en stories, c’est-à-dire que les fonctionnalités de votre PBB Canvas seront détaillées dans des user stories.
Ainsi, pendant le Sprint, l’équipe Scrum travaille sur les user stories. Dans Sprint Review, l’équipe vérifiera la progression de ces user stories, leurs fonctionnalités et l’incrément du produit. Ensuite, l’équipe Scrum continue de travailler, l’incrément est livré et l’équipe continue de travailler sur les prochaines fonctionnalités et user stories pour le prochain incrément de produit.
User stories d’utilisateurs dans Kanban
Une autre méthode largement reconnue est Kanban, créée par David J. Anderson. Il est largement utilisé pour gérer le workflow d’un processus incrémental et évolutif. Ainsi, il est possible d’avoir une vision partagée de toutes les phases du workflow, des personnes et des tâches à effectuer.
Kanban recommande de limiter les travaux en cours (work-in-progress WIP en anglais). Par conséquent, un « système d’extraction » se produit, c’est-à-dire qu’un nouveau travail n’est « tiré » vers la nouvelle étape que lorsqu’il y a de la capacité disponible dans la limite WIP. Cela permet de l’organisation, de la planification, de l’agilité et ne surcharge pas l’équipe.
Dans un tableau Kanban simplifié, vous assemblerez et diviserez votre travail en cours avec les prochaines fonctionnalités et user stories (To Do), celles qui sont en cours (Doing) et, dans la dernière colonne, les fonctionnalités qui sont déjà prêtes ( Terminé). Lorsque vous avez terminé toutes les user stories d’une fonctionnalité, vous ouvrez un espace sur le tableau et ouvrez la fonctionnalité suivante.
Une grande partie de ce contenu provient du livre PBB, un peu du livre Lean Inception et, un peu plus, d’autres articles et du livre électronique et de la formation Lean Delivery.
Ce contenu a été écrit et compilé par Paulo Caroli et révisé par Fábio Aguiar.
Avez-vous aimé ce contenu ?
>> Consultez ensuite le livre PBB et la formation PBB.
>> Sur la page du livre PBB, vous trouverez également d’excellents documents (DoR, DoD, ACs, etc.) à télécharger au format PDF.
Sur Caroli.org, il existe, entre autres, divers documents liés au sujet. Accédez maintenant et poursuivez vos connaissances et votre processus d’apprentissage, ainsi que la création d’un produit réussi.
