Élaboration d’un récit utilisateur

Objectifs de formation

Une fois cette unité terminée, vous pourrez :

Souligner l’importance d’établir des critères d’acceptation
Résumer le concept INVEST relatif à la rédaction d’un récit utilisateur
Identifier les erreurs courantes à éviter lors de la rédaction d’un récit utilisateur

Réunion de l’équipe de projet

Il est recommandé d’organiser un atelier de rédaction de récits utilisateur aux alentours du lancement d’un projet. L’organisation d’ateliers de rédaction de récits permet de réunir l’équipe d’un projet : on y retrouve le(s) responsable(s) produit, le(s) développeur(s), un ou plusieurs administrateurs, le(s) concepteur(s) de l’expérience utilisateur, des utilisateurs, etc. Les participants réfléchissent ensemble pour trouver des idées de récits. Lors de la création des récits utilisateur, la créativité de toute l’équipe doit être sollicitée. En outre, ces récits utilisateur initiaux ne sont pas gravés dans le marbre. Tout l’intérêt des récits utilisateur est qu’ils se prêtent bien au développement par cycles et peuvent être affinés autant de fois que nécessaire.

Lorsque vous formulez des récits utilisateur avec votre équipe de projet, ne faites aucune hypothèse sur la manière dont les récits utilisateur seront mis en œuvre, par exemple en supposant quels composants ou services seront concernés. C’est l’équipe de développement/d’implémentation qui précisera ces aspects lors de ses réunions de planification.

Les critères, des éléments essentiels

Il est normal que lorsqu’un groupe de projet se réunit, un même problème soit vu sous des angles différents. Ces différentes perspectives sont tout à fait nécessaires et utiles, mais peuvent se révéler frustrantes si vous ne vous mettez pas d’accord sur une manière de mesurer la réussite, que l’on connaît sous le nom de critères d’acceptation. Les critères d’acceptation sont un ensemble d’énoncés, chacun avec un résultat clair de réussite/échec, ajoutés à un récit utilisateur. Pour le dire simplement, les critères d’acceptation précisent les conditions dans lesquelles un récit utilisateur est satisfait. Ils doivent être exprimés clairement, dans un vocabulaire simple, sans aucune ambiguïté sur le résultat attendu. Lorsque les critères d’acceptation sont bien rédigés, cela a une incidence positive sur plusieurs étapes et parties prenantes d’un projet. En effet, ils participent notamment à :

clarifier le cahier des charges pour l’équipe de projet ;
appuyer l’action de l’équipe de développement/d’implémentation ;
faire en sorte que les testeurs sachent ce qui doit être vérifié.

Les critères d’acceptation doivent indiquer une intention, mais pas une solution. Réfléchissez au « quoi », et non au « comment ».

Voici un mauvais exemple de critère d’acceptation (car il se concentre sur une solution) : un responsable régional peut cliquer sur un bouton Approuver/Refuser pour approuver une remise sur le prix d’un produit.
Voici maintenant un bon exemple de critère d’acceptation (car il se concentre sur une intention) : un responsable régional peut approuver ou désapprouver une remise sur le prix d’un produit.

Une fois la session de rédaction du récit utilisateur terminée, il est temps d’ajouter à celui- ci les critères d’acceptation. Revenons au récit utilisateur de l’unité précédente.

Exemple de récit utilisateur : en tant que représentant du service client, je veux pouvoir me définir comme propriétaire des nouvelles requêtes et communiquer avec les clients afin de pouvoir leur offrir des expériences d’une qualité exceptionnelle.

Voici des exemples de critères d’acceptation pour ce récit utilisateur :

Pouvoir se définir comme propriétaire des requêtes à partir de la file d’attente.
Pouvoir envoyer des e-mails aux clients depuis les pages de requête.
Pouvoir mettre à jour les détails des requêtes, à savoir leur statut, leur sujet et leur description.

Les critères d’acceptation peuvent également prendre la forme d’instructions conditionnelles. Voici les critères d’acceptation ci-dessus écrits sous forme d’instruction conditionnelle : si je me trouve sur une page de requête, alors la fonctionnalité permettant d’envoyer un e-mail au client doit être accessible. Quel que soit le format de rédaction, chaque récit utilisateur doit comporter au moins un critère d’acceptation. Vous devez pouvoir tester chaque critère indépendamment et y répondre par vrai ou faux.

Vous avez l’impression de maîtriser les critères d’acceptation ? Passons maintenant à un peu de pratique. Sélectionnez les critères d’acceptation applicables à l’exemple de récit utilisateur indiqué.

Vous vous demandez peut-être comment vous allez faire pour vous souvenir de tous ces détails lors de la rédaction des récits utilisateur et des critères d’acceptation ? Astuce : nous allons investir notre temps dans la mémorisation d’un acronyme.

Investissement dans le récit utilisateur

Si votre liste de tâches personnelle mentionne une activité telle que « découvrir une nouvelle liste de contrôle », nous avons une bonne nouvelle pour vous ! En effet, vous allez pouvoir la rayer de votre liste. Les analystes commerciaux Salesforce peuvent utiliser la liste de contrôle INVEST (élaborée par Bill Wake en 2003) pour évaluer la qualité d’un récit utilisateur. Si le récit utilisateur ne satisfait pas aux exigences de l’un des points, cela signifie qu’il est probablement nécessaire de le réécrire.

Un récit utilisateur réussi est :

Indépendant : les récits utilisateur doivent être indépendants et ne pas reprendre le principe d’un autre récit utilisateur.
Négociable : un récit utilisateur n’est pas un contrat. C’est une invitation à la conversation. Il saisit l’essence d’une problématique, pas ses détails.
Vecteur de valeur ajoutée : le récit utilisateur doit être utile à l’utilisateur final. Si un récit n’apporte pas de valeur ajoutée, il ne doit pas être écrit.
Estimable : lorsqu’un récit utilisateur est bien conçu, il est possible d’estimer le calendrier de mise en œuvre qui lui est associé. L’estimation n’a pas à être exacte, mais doit être suffisamment précise pour permettre de hiérarchiser et planifier le développement/l’implémentation du récit.
Succinct : les récits utilisateur les plus efficaces sont brefs. Cette concision vous permet généralement d’obtenir des estimations de calendrier plus précises. N’oubliez pas que les détails peuvent être précisés lors des échanges ultérieurs.
Testable : un bon récit utilisateur peut être testé. Lorsqu’un récit est bien rédigé, n’importe quel membre de l’équipe de projet peut le lire et dire : « Oui, je comprends tellement bien ce récit utilisateur que je peux rédiger des critères d’acceptation le concernant. »

Erreurs à éviter

Des erreurs peuvent se produire lors de tout processus qui implique plusieurs étapes, et la rédaction de récits utilisateur n’y fait pas exception. Heureusement, comme les récits utilisateurs peuvent être ajustés, vous aurez toujours la possibilité de remédier à ces faux pas. Toutefois, cela ne vous empêche pas d’essayer de faire de votre mieux pour éviter les erreurs dès le départ. Voici quelques erreurs couramment commises lors de l’élaboration des récits utilisateur et des conseils sur la manière dont un analyste commercial Salesforce peut les éviter.

L’équipe de projet ne s’est pas impliquée dans la rédaction du récit.

Conséquence : le récit utilisateur ne représentera pas les multiples perspectives de l’équipe de projet. Le récit devra obligatoirement être remanié en profondeur.
Comment éviter cette erreur : planifiez une séance de rédaction du récit au début du projet. Examinez en permanence le récit utilisateur avec les membres de l’équipe de projet et échangez constamment avec eux à son sujet.

Le « qui » du récit utilisateur ne correspond pas à un utilisateur défini.

Conséquence : l’équipe de développement aura du mal à comprendre en quoi les motivations et les besoins de cet utilisateur sont pertinents, car ce dernier n’est pas défini. Le récit utilisateur ne produira pas le résultat escompté.
Comment éviter cette erreur : avant de créer un récit utilisateur, dressez la liste des profils d’utilisateurs définis. Ces profils bien définis peuvent être utilisés comme référence lors de la création d’un récit utilisateur, du développement/de l’implémentation de la ou des solutions, ainsi que lors des tests.

Le « pourquoi » du récit utilisateur est axé sur une fonctionnalité précise.

Conséquence : le récit utilisateur est trop technique et centré sur des détails ; il se lit davantage comme une description de l’outil que comme un récit. Les besoins des utilisateurs ne sont pas pris en compte.
Comment éviter cette erreur : les besoins de l’utilisateur doivent rester votre priorité. Examinez le récit utilisateur après l’avoir écrit pour vérifier s’il n’est pas trop centré sur des détails. Restez toujours ouvert aux commentaires de l’équipe de projet.

Les critères d’acceptation sont trop vagues.

Conséquence : sans critères d’acceptation spécifiques qu’il est possible de tester, il n’existe aucun moyen fiable d’évaluer à quel moment le récit utilisateur est satisfait.
Comment éviter cette erreur : assurez-vous que tous les critères d’acceptation sont indépendants et que vous pouvez y répondre par vrai ou faux. Collaborez avec l’équipe de projet pour rédiger des critères d’acceptation qui correspondent à l’objectif de l’utilisateur.

Le récit utilisateur a été attribué à l’équipe d’implémentation alors qu’elle n’a participé à aucun échange à son sujet.

Conséquence : la probabilité que le récit utilisateur soit mal interprété pendant le développement devient beaucoup plus forte. Le produit final risque d’être éloigné de ce qui était prévu.
Comment éviter cette erreur : passez en revue les récits avec votre équipe lorsque vous les leur attribuez. Examinez les détails, mettez en évidence l’intention et assurez-vous que l’équipe est sur la même longueur d’onde que vous.

Comme vous pouvez le voir, toutes ces erreurs peuvent être évitées lorsque le processus de rédaction de récits utilisateur est correctement suivi. Ne prenez pas de raccourci. Faites confiance au processus et vous finirez par obtenir une solution axée sur la réussite des clients/utilisateurs finaux.

Finalement, nous ne sommes plus si loin de notre définition évidente du début : les récits utilisateur sont bien des récits à propos des utilisateurs, n’est-ce pas ? Vous avez beaucoup appris sur les récits utilisateur, et découvert notamment leurs objectifs, leurs composantes, les acteurs à impliquer lorsque vous les créez, la manière de les tester et les erreurs à éviter lorsque vous les élaborez. De plus, vous connaissez désormais un acronyme qui vous aide à les évaluer. Maintenant, mettez à profit vos nouvelles connaissances sur cette thématique pour rédiger des récits sur les utilisateurs.