10 Conseils aux PO pour rédiger de bonnes User Stories
Les user stories (User Story ou encore récit utilisateur en français) sont probablement la technique agile la plus populaire pour illustrer les fonctionnalités d’un produit. Utiliser les user stories permet notamment de simplifier le travail. Cependant, elles peuvent être difficiles à rédiger avec pertinence.
Les dix conseils suivants vous aideront à créer de meilleures User Stories.
Voici nos 10 conseils pour de bonnes User Stories :
- Les utilisateurs passent avant tout
- Utilisez des Personas afin de mettre en forme des User Stories pertinentes
- Créez vos User Stories en équipe
- Privilégiez la simplicité et la concision
- Vos User Stories doivent ressembler à des “épopées”
- Affinez vos User Stories jusqu’à ce qu’elles soient au point
- Ajoutez des critères d’acceptation
- Utilisez des feuilles de papier pour illustrer de façon concrète vos User Stories
- Gardez les User Stories visibles et accessibles
- Ne vous fiez pas uniquement aux User Stories
1. User Story : Les utilisateurs passent avant tout
Comme son nom l’indique, une User Story décrit la manière dont un client ou un utilisateur utilise le produit. Elle a la particularité d’être racontée depuis le point de vue de l’utilisateur. Elles sont en outre particulièrement utiles pour capturer une fonctionnalité spécifique, comme la recherche d’un produit ou la réservation. Le schéma suivant illustre la relation entre l’utilisateur, l’histoire et la fonctionnalité du produit (symbolisée par le cercle).
Si vous ne savez pas encore qui sont les utilisateurs et les clients et pourquoi ils veulent utiliser le produit, vous ne devriez pas écrire d’histoires d’utilisateur. Commencez par effectuer dans un premier temps les recherches nécessaires sur les utilisateurs. Vous pouvez par exemple observer et interroger les utilisateurs. Faute de quoi, vous prenez le risque d’écrire des histoires spéculatives fondées sur des croyances et des idées, et non sur des données et des preuves empiriques.
2. User Story : Utilisez des Personas afin de mettre en forme des User Stories pertinentes
Les personas constituent une excellente approche pour recueillir des données sur les utilisateurs et les clients. Ce sont des personnages fictifs basés sur des connaissances de base du groupe cible. Ils se composent généralement d’un nom et d’une image, de caractéristiques, de comportements et d’attitudes pertinents et d’un objectif. La finalité de cet exercice est le bénéfice que le persona veut obtenir, ou le problème que le persona veut résoudre en utilisant le produit.
Mais ce n’est pas tout : les objectifs du persona vous aident à déterminer les bonnes User Stories. Posez-vous la question de savoir quelle fonctionnalité le produit doit fournir pour atteindre les objectifs du persona en question.
3. User Stories : Créez vos User Stories en équipe
Les user stories sont conçues comme une technique de travail très souple qui vous permet d’avancer rapidement. Elles ne représentent pas un cahier des charges précis, mais un outil de collaboration. Elles ne doivent jamais être remises à une équipe de développement. Au contraire, elles doivent être intégrées dans un dialogue. Le Product Owner et son équipe doivent en discuter ensemble. Cela vous permet de recueillir seulement le strict minimum d’informations et donc de réduire les frais généraux et d’accélérer la livraison.
Vous pouvez approfondir cette approche en rédigeant les User Stories en collaboration totale, dans le cadre du processus de préparation de votre backlog. Cela permet de tirer parti de la créativité et des connaissances de l’équipe et d’obtenir de meilleurs résultats.
Si vous êtes dans l’impossibilité d’impliquer l’équipe de développement dans le travail sur les user stories, vous devez envisager d’utiliser une autre technique, plus formelle, pour appréhender les fonctionnalités du produit, comme les user cases (cas d’utilisation).
4. User Stories : Privilégiez la simplicité et la concision
Rédigez vos user stories de manière à ce qu’elles soient faciles à comprendre. Restez simple et concis. Évitez les termes confus et ambigus, et utilisez la voix active. Concentrez-vous sur ce qui est important. Le modèle présenté ci-dessous place l’utilisateur ou le client représenté sous la forme d’un persona dans la story et rend ses bénéfices attendus explicites. Il est basé sur le modèle populaire de Rachel Davies, mais nous avons remplacé le rôle de l’utilisateur par le nom du persona afin de relier l’histoire au persona en question.
En tant que (persona), je veux (quoi?) de sorte que (pourquoi?).
Utilisez ce modèle lorsqu’il est nécessaire seulement. Cependant, ne vous sentez pas obligé de systématiquement l’appliquer. Expérimentez différentes manières de formuler vos User Stories pour comprendre ce qui fonctionne le mieux pour vous et votre équipe.
5. Vos User Stories doivent ressembler à des “épopées”
Une épopée est une longue histoire, peu détaillée et approximative. Dans le cadre de la gestion de projet, elle est généralement divisée en plusieurs user stories au fil du temps, en tirant parti des commentaires des utilisateurs sur les premiers prototypes et les premières versions du produit. Vous pouvez la considérer comme un titre et un support pour les user stories plus détaillées qui vont suivre.
Commencer par des “épopées” vous permet de définir les fonctionnalités du produit sans pour autant entrer dans les détails. C’est particulièrement utile pour décrire les nouveaux produits et les nouvelles fonctionnalités. Cela vous permet de définir un premier niveau de fonctionnalités et de gagner du temps pour en savoir plus sur la façon de répondre aux besoins des utilisateurs.
Cette méthode réduit également le temps et les efforts nécessaires pour intégrer de nouvelles informations. Si vous avez beaucoup d’user stories détaillées dans le backlog du produit, il est souvent complexe et fastidieux de relier le feedback aux éléments appropriés et cela entraîne le risque d’introduire des contradictions.
6. User Story : Affinez vos User Stories jusqu’à ce qu’elles soient au point
Décomposez vos “épopées” en stories plus courtes et détaillées jusqu’à ce qu’elles soient prêtes. Cela signifie que les User Stories doivent être claires, réalisables et vérifiables. Tous les membres de l’équipe de développement doivent avoir une compréhension similaire de la signification de vos User Stories. Elles ne doivent pas être trop longues et elles doivent s’intégrer facilement dans un sprint. Enfin, il doit y avoir un moyen efficace de déterminer si la story est terminée.
7. Users Stories : Ajoutez des critères d’acceptation
Lorsque vous divisez les “épopées” en plus petites stories, n’oubliez pas de préciser les critères d’acceptation. Les critères d’acceptation complètent les User Stories. Ils vous permettent de décrire les conditions qui doivent être remplies pour que la story soit respectée. Les critères d’acceptation sont enrichissants : ils les rendent testables et ils garantissent que la story peut faire l’objet d’une démo ou d’une diffusion auprès des utilisateurs et des autres parties prenantes. En règle générale, il est recommandé d’utiliser trois à cinq critères d’acceptation pour les récits utilisateurs les plus détaillés.
Pour aller plus loin sur cette notion, découvrez notre article du blog du testeur sur les critères d’acceptation : leurs objectifs, formats et meilleures pratiques.
8. User story : Utilisez des fiches en papier pour illustrer de façon concrète vos User stories
Les User stories sont apparues dans le cadre de l’Extreme Programming (XP). Les premiers ouvrages sur l’XP parlent de Story Cards plutôt que d’User Stories. La raison est simple : Les User stories étaient présentées sur des fiches en papier.
Cette approche présente trois avantages :
– Premièrement, les fiches en papier sont bon marché et faciles à utiliser.
– Deuxièmement, elles facilitent la collaboration : Chacun peut prendre une carte et noter une idée.
– Troisièmement, les cartes d’User Stories peuvent être facilement regroupées sur la table ou le mur pour vérifier la cohérence et l’exhaustivité et pour visualiser les dépendances. Même si vos User Stories sont stockées sous forme numérique, il est utile d’utiliser des fiches en papier lorsque vous écrivez de nouvelles histoires.
9. User story : Gardez les User Stories visibles et accessibles
Les User Stories visent à communiquer des informations. Par conséquent, ne les cachez pas sur un fichier du serveur, dans la jungle de l’intranet de l’entreprise ou dans un outil sous licence. Faites en sorte qu’elles soient visibles, par exemple en les affichant au mur. Cela favorise la collaboration, crée de la transparence et permet de se rendre compte que vous ajoutez trop d’User Stories trop rapidement (car vous commencerez à manquer d’espace sur le mur). Il existe également des outils en ligne comme Jira qui vous permettent de les rendre vos accessibles à tous à travers un support numérique.
10. User Story : Ne vous fiez pas uniquement aux User Stories
Pour créer une expérience utilisateur (UX) de qualité, il faut aller au-delà des User Stories. Elles sont utiles pour illustrer les fonctionnalités du produit, mais elles ne sont pas adaptées pour décrire les parcours des utilisateurs et la présentation visuelle. Il faut donc compléter les user stories par d’autres techniques, comme les story maps, les diagrammes de flux de travail (workflow), les storyboards, les croquis et les maquettes.
En outre, les user stories ne permettent pas de capturer les exigences techniques. Si vous devez communiquer ce qu’un élément architectural comme un composant ou un service doit faire, alors écrivez des histoires techniques ou utilisez un langage de modélisation.
Enfin, leur rédaction est utile lorsque vous développez des logiciels susceptibles d’être réutilisés. Mais si vous voulez créer rapidement un prototype ou une maquette pour valider une idée, il n’est peut-être pas nécessaire de le faire. N’oubliez pas : le but des User Stories n’est pas de documenter les exigences ; elles représentent un outil qui va vous permettre d’aller vite et de développer un logiciel aussi rapidement que possible – et non pas vous imposer des contraintes.
Exemple d’User Stories
User Story : Création d’une nouvelle tâche
En tant qu’utilisateur, je souhaite pouvoir créer une nouvelle tâche, afin de pouvoir la gérer et la suivre.
Critères d’acceptation :
- Je peux indiquer le nom de la tâche.
- Je peux ajouter une description de la tâche.
- Je peux attribuer un niveau de priorité à la tâche.
- Je peux fixer une date d’échéance pour la tâche.
- Une fois toutes les informations entrées, je peux sauvegarder la tâche dans mon espace de gestion des tâches.
User Story : Modification d’une tâche existante
En tant qu’utilisateur, je souhaite pouvoir modifier une tâche existante, afin de pouvoir mettre à jour les informations ou l’état de la tâche.
Critères d’acceptation :
- Je peux sélectionner une tâche existante dans mon espace de gestion des tâches.
- Je peux modifier le nom, la description, le niveau de priorité ou la date d’échéance de la tâche.
- Je peux modifier l’état de la tâche (à faire, en cours, terminé).
- Une fois les modifications effectuées, je peux sauvegarder les modifications dans mon espace de gestion des tâches.
Ces exemples d’User Stories, découpées en différents blocs, facilitent la compréhension de l’utilisateur, son rôle, ses souhaits et les critères nécessaires pour satisfaire ses besoins.
Conclusion : User Stories
Nous espérons que cet article vous aura éclairés ou conforté dans vos connaissances.
Pour aller plus loin sur la thématique générale de la gestion de produit/projet et notamment dans un environnement agile, vous pouvez consulter nos autres articles à destination des products owners et, plus largement, à destination des membres d’une équipe de gestion de projet :
- Le rôle du product owner dans la conception du logiciel en méthode agile
- 10 conseils pour les PO en mode agile sur la gestion de produit
Et pour finir, un message aux Product Owners : formez-vous à BDD, c’est un must have car c’est une méthode de conception de spécifications drivé par l’exemple😉
Si vous souhaitez vous formez à l’UX (expérience utilisateur) notre partenaire UpSkill4IT propose une formation sur l’UX design.
Si vous avez besoin d’aide concernant la rédaction des User Stories ou concernant des services d’Audit ou de Consulting sur vos projets, n’hésitez pas à nous contacter !
Source et images : Roman Pichler
