10 Conseils aux PO pour rédiger de bonnes User Stories

Les user stories (ou récit utilisateur en français) sont probablement la technique agile la plus populaire pour illustrer les fonctionnalités d’un produit. Les utiliser 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 :

  1. Les utilisateurs passent avant tout
  2. Utilisez des Personas afin de mettre en forme des User Stories pertinentes
  3. Créez vos User Stories en équipe
  4. Privilégiez la simplicité et la concision
  5. Vos User Stories doivent ressembler à des « épopées »
  6. Affinez vos User Stories jusqu’à ce qu’elles soient au point
  7. Ajoutez des critères d’acceptation
  8. Utilisez des feuilles de papier pour illustrer de façon concrète vos User Stories
  9. Gardez les User Stories visibles et accessibles
  10. Ne vous fiez pas uniquement aux User Stories

1. 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).

relation entre l'utilisateur, l'histoire et la fonctionnalité du produit dans une User Story

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. 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.

Retour des utilisateurs, Personas et User stories

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. 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).

Implication de l'équipe de développement dans la conception des User stories

4. 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 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. 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 qu’elles sont 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 la story. Elle ne doit pas être trop longue et elle doit s’intégrer facilement dans un sprint. Enfin, il doit y avoir un moyen efficace de déterminer si la story est terminée.

Cheminement vers les versions finales

7. 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.

Les User Story et les critères d'acceptation


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. 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 de 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 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.

Utilisez des fiches en papier pour vos User Stories

9. 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.

Des User Stories affichées sur un tableau

10. 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 : leur but 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.

Nous espérons que cet article vous aura éclairé 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 consultez nos autres articles à destination des product owners et, plus largement, à destination des membres d’une équipe de gestion de projet : 

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 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