Les critères INVEST servent de boussole pour naviguer dans le processus complexe de création de User Stories. Cet article plonge au cœur de ces critères, offrant un éclairage sur comment ces principes peuvent transformer des User Stories de simples idées en outils puissants pour la réalisation de projets Agile.
Qu'est-ce qu'une User Story (Récit Utilisateur) ?
Les User Stories, ou Récits Utilisateurs, sont le cœur de toute méthodologie Agile. Elles aident à capturer les besoins et les attentes des utilisateurs de manière simple et directe. Une User Story bien formulée facilite la communication entre l’équipe de développement et les parties prenantes, assurant ainsi que le produit final répond aux besoins des utilisateurs.
Comment rédiger une bonne User Story ?
Lors de la rédaction d’une User Story agile, il est crucial de suivre une structure claire et centrée sur l’utilisateur. Voici un guide détaillé :
Commencer par "En tant que" (ou répondez à la question Qui?) :
Chaque User Story débute par l’identification du type d’utilisateur. Cela oriente la fonctionnalité du point de vue de celui qui va l’utiliser, en s’assurant que le développement répond à un besoin réel. Par exemple, “En tant que administrateur”.
"Je veux" (Quoi?) :
Cette partie décrit l’action ou la fonctionnalité désirée. Elle doit être claire et concise, évitant les termes techniques pour rester compréhensible par tous. Par exemple, “Je veux pouvoir ajouter de nouveaux produits sur mon site e-commerce”.
"Afin de" (Pourquoi?) :
Cette section indique le but ou le bénéfice de la fonctionnalité. Elle relie la demande à un avantage ou une valeur pour l’utilisateur, renforçant ainsi l’importance de la User Story.
En respectant cette structure en trois points, les User Stories aident le Product Owner à clarifier le ‘Qui’, le ‘Quoi’ et le ‘Pourquoi’, sans empiéter sur le ‘Comment’ (la technique). Cela laisse une marge importante aux développeurs de l’équipe Scrum pour innover et trouver la meilleure solution technique, tout en se concentrant clairement sur les besoins essentiels des utilisateurs.
Exemple de User Story (qu'on utilisera tout au long de l'article) :
Voici un bon exemple de User Story sur lequel nous allons nous baser dans cet article :
Titre : “Amélioration de la barre de Recherche de Produits dans le Catalogue”
Contenu de l’US : “En tant que client, je veux pouvoir filtrer les produits par prix, catégories, et notes des clients, afin de trouver rapidement ce que je cherche.”
Cette User Story illustre une compréhension claire et concise du besoin du client, tout en restant flexible pour des ajustements ultérieurs. Elle favorise la collaboration entre l’équipe et le Product Owner, où les détails et les solutions peuvent émerger à travers un dialogue ouvert, contrairement à un cahier des charges rigide que l’équipe de développement doit suivre à la lettre. Cet exemple démontre l’importance de la clarté, de la pertinence et de l’adaptabilité dans la rédaction des User Stories en Agile.
Définitions des Critères INVEST d'une User Story
En tant que Scrum Master ou Product Owner, il est crucial de guider l’équipe Scrum vers la création de User Stories qui intègrent efficacement les critères INVEST. Chacun de ces critères joue un rôle spécifique dans l’amélioration de la qualité et de la pertinence des User Stories dans le Product Backlog :
User Story Indépendante
Pour commencer, chaque User Story doit être “Indépendante”. Cela signifie qu’elle peut être développée et testée de manière isolée, sans dépendre d’autres Stories. Cette indépendance permet une plus grande flexibilité dans la planification et la priorisation des tâches.
Par exemple, si une Story pour un site e-commerce dépend de la mise en place d’un système de paiement, envisagez de simuler temporairement la fonctionnalité de paiement. Cela permet à l’équipe de progresser sans être bloquée par d’autres tâches.
US Négociable
Ensuite, chaque Story est “Négociable”. Cela implique qu’elle n’est pas un contrat figé, mais plutôt un point de départ pour la discussion. Les détails techniques ne sont pas gravés dans le marbre mais sont plutôt adaptés selon les besoins et la compréhension de l’équipe.
Les Récits Utilisateurs doivent être ouvertes à la discussion et à l’adaptation. Elles servent de base pour les conversations, où l’équipe de développement et le Product Owner peuvent explorer différentes options et solutions, garantissant ainsi que la Story finale est bien alignée avec les besoins réels des clients.
Apporter de la Valeur
Chaque User Story doit apporter une valeur. Nous devons toujours nous demander : “Cette Story apporte-t-elle une valeur réelle à l’utilisateur final ?” Chaque Story doit contribuer de manière significative à la satisfaction des besoins des utilisateurs.
Récit utilisateur Estimable
“Estimable” est un principe essentiel. Une User Story doit être suffisamment claire pour que l’équipe puisse estimer le temps et les efforts nécessaires à sa réalisation. Cette estimabilité facilite la planification et contribue à une meilleure gestion des attentes.
Petites (Small)
Ecrivez des user stories plus petites (Small), c’est-à-dire de taille gérable. Elle doit pouvoir être suffisamment petite pour être développée et testée au sein d’un seul Sprint, mais assez complète pour offrir une valeur ajoutée.
User Story Testables
Enfin, chaque User Story doit être “Testable”. Il doit être possible de vérifier si les objectifs de la Story ont été atteints grâce à des critères de test clairs. Cette testabilité assure que la Story remplit bien sa fonction et répond aux besoins des utilisateurs.
Par exemple, pour notre Story de recherche et filtrage sur un site e-commerce, les critères de test pourraient inclure la vérification que les filtres produisent les bons résultats et que la performance du site reste stable. Cette testabilité garantit non seulement que les objectifs de l’US sont atteints, mais aide également à identifier et résoudre les problèmes potentiels dès le début du processus de développement.
En quoi notre exemple de User Story est INVEST
La Story que nous utilisons en exemple (“En tant que client, je veux pouvoir filtrer les produits par prix, catégories, et notes des clients, afin de trouver rapidement ce que je cherche”) est INVEST car elle est :
- Indépendante : Elle peut être développée séparément des autres fonctionnalités du site.
- Négociable : Les détails spécifiques du filtrage peuvent être ajustés en fonction des besoins des clients et des capacités techniques.
- Valeur : Elle offre une valeur ajoutée significative en améliorant l’expérience utilisateur sur le site.
- Estimable : L’équipe de développement peut évaluer le temps et les ressources nécessaires pour implémenter cette fonctionnalité.
- Small : La tâche est suffisamment petite pour être réalisée dans un sprint.
- Testable : Des critères de test clairs peuvent être établis pour vérifier la fonctionnalité.
Des Vidéos Intéressantes sur Youtube pour comprendre INVEST en quelques minutes
FAQ sur les User Stories et la Méthode INVEST en Agile
L’acronyme INVEST aide à clarifier et à définir des objectifs précis pour chaque Story, améliorant ainsi la planification et l’exécution des tâches lors du Sprint. Il favorise également la transparence et la collaboration au sein de l’équipe. En mettant en place ces critères pendant les réunions de Backlog Refinement, on veille à ce que chaque US est prête à être développée par les équipes de développement lors des prochains Sprints.
Utilisation de champs personnalisés :
- Commencez par vérifier si votre instance Jira prend en charge les champs personnalisés. Si ce n’est pas le cas, contactez l’administrateur Jira pour les ajouter si nécessaire.
- Créez un champ personnalisé de type “Checklist” ou “Liste de vérification” dans Jira. Chaque élément de cette liste représentera un critère INVEST.
- Lorsque vous créez une nouvelle User Story, remplissez le champ de la liste de vérification avec les critères INVEST pertinents.
2. Utilisation de la description de la User Story :
- Vous pouvez également intégrer les critères INVEST en les ajoutant manuellement à la description de la User Story. Lorsque vous créez une User Story, incluez une liste de vérification des critères INVEST dans la description de la manière suivante :
3. Utilisation de Jira Automation (le cas échéant) :
- Si vous souhaitez automatiser l’ajout de critères INVEST dans la description lors de la création de User Stories, explorez les possibilités offertes par Jira Automation en utilisant des règles personnalisées pour cette tâche.
Pour rendre une User Story indépendante, identifiez les éléments qui la rendent dépendante d’autres Stories. Ensuite, envisagez de modifier la Story pour éliminer ces dépendances, ou utilisez des “stubs” ou bouchons ou des simulations pour les fonctionnalités non encore développées. Ainsi le Récit Utilisateur peut être développée et testée indépendamment, sans attendre la finalisation des autres fonctionnalités.
Une bonne US doit être claire, concise, et centrée sur l’utilisateur. Elle doit clairement décrire le besoin du client et le bénéfice attendu. La structure classique “En tant que [utilisateur], je veux [action ou fonctionnalité] afin de [résultat ou bénéfice]” aide à garder le focus sur les objectifs de la fonctionnalité à développer.
Chez Leading Change les développeurs jouent un rôle crucial dans la formulation des user stories, en apportant leur expertise technique pour s’assurer que les stories sont réalisables et testables. Ils collaborent étroitement avec le Product Owner pour affiner les détails et s’assurer que chaque story apporte de la valeur.
Dans la méthode Scrum, pour prioriser plusieurs user stories dans un balcklog produit il est préférable d’utiliser des méthodes de priorisations efficaces et adaptées à votre contexte. Dans la section de notre Blog : Techniques de Priorisation, vous trouverez un ensemble d’articles que nous avons créé qui abordent en profondeur plusieurs Frameworks de priorisation.
