Guide Scrum | 20. INVEST – Créer la meilleure User Story

INVEST est une méthode pour créer de bonnes User Stories. Elle permet de vérifier si elles contiennent un contenu correctement formulé et si elles se rapportent à la valeur commerciale du Produit. Et aussi, si leur taille et leur utilisabilité ont été choisies correctement.

Créer la meilleure User Story avec INVEST – table des matières :

1. Introduction
2. I pour Indépendant
3. N pour Négociable
4. V pour Précieux ou Vertical
5. E pour Estimable
6. S pour Petit
7. T pour Testable
8. Résumé

Introduction

INVEST est un acronyme créé par Bill Wake en 2003. Chaque lettre de cet acronyme représente le début d’un mot qui caractérise une bonne User Story. Selon le principe INVEST, chaque User Story devrait être :

• Indépendante
• Négociable
• Précieuse
• Estimable
• Petite
• Testable

Nous avons écrit plus sur ce qu’est une User Story dans un article séparé. Ici, nous mentionnerons seulement qu’il s’agit d’une description concise d’une nouvelle fonctionnalité du Produit rédigée dans un langage accessible.

I pour Indépendant

La première caractéristique d’une bonne User Story est son indépendance. Cela signifie que sa description et ses caractéristiques doivent être compréhensibles sans référence à d’autres User Stories. Mais surtout, sa réalisation ne doit pas être corrélée à d’autres User Stories. Bien sûr, cela ne sera pas une indépendance totale. Vous ne pouvez pas diviser la création du Produit en modules complètement séparés. Cependant, il est crucial de garder les User Stories aussi indépendantes que possible. Grâce à cela, même si l’une d’elles n’entre pas en phase de mise en œuvre ou est modifiée de manière significative, les autres n’auront pas besoin d’être modifiées. En règle générale, la User Story doit constituer un tout séparé et cohérent.

N pour Négociable

La User Story doit être négociable. Cela signifie qu’elle fixe l’objectif, pas le moyen d’y parvenir.

En d’autres termes, elle définit une fonctionnalité attendue du Produit, pas une solution technique à mettre en œuvre.

La négociation de la User Story a lieu entre le Product Owner et l’équipe de développement. Le Product Owner propose la mise en œuvre de certaines fonctionnalités du Produit, c’est-à-dire qu’il dit “Quoi” faire. Les développeurs sont responsables de répondre à la question “Comment”. C’est-à-dire négocier des moyens spécifiques de résoudre le problème présenté dans la User Story.

V pour Précieux ou Vertical

Dans l’acronyme INVEST, la lettre V représente deux qualités :

• Précieux
• Vertical

Les deux révèlent des caractéristiques clés d’une bonne User Story. Par conséquent, nous avons décidé d’expliquer ce que chacune d’elles signifie.

Précieux

Une User Story précieuse justifie le but commercial de la modification. En d’autres termes, elle répond précisément à la question de pourquoi la modification doit être introduite et pourquoi elle est importante du point de vue des parties prenantes.

Vertical

La deuxième caractéristique ; Vertical découle de la méthodologie Agile. La User Story verticale contient une nouvelle fonctionnalité du Produit visible par l’Utilisateur. C’est-à-dire qu’elle ne se concentre pas sur une “amélioration de performance” horizontale dans une couche sélectionnée du Produit. Au contraire, elle ajoute une autre “couche” à celui-ci.

En d’autres termes, la User Story décrit comment modifier le fonctionnement global d’un Produit en répondant à la question Qu’est-ce qu’il faut améliorer exactement ? Cela signifie également que chaque fonctionnalité du Produit s’appuie sur des solutions existantes.

E pour Estimable

Une bonne User Story doit être estimable. Cela signifie qu’elle doit clairement définir l’étendue des modifications à apporter au produit pour que la User Story soit considérée comme complète. Cela permet à l’équipe de développement de déterminer le temps et l’effort nécessaires pour la réaliser.

L’étendue et la difficulté d’une tâche sont généralement estimées en unités appelées Story Points. Elles sont relatives. Et chaque équipe de développement établit la valeur des Story Points en pratique sur la base de l’expérience précédente.

Dans des articles séparés, nous avons couvert plus sur la vélocité de l’équipe de développement et comment la mesurer.

S pour Petit

La User Story acceptée pour réalisation par l’équipe de développement doit être concise. C’est-à-dire elle ne doit pas dépasser une Sprint. Si les développeurs découvrent lors de la planification de la Sprint que la User Story proposée par le Product Owner est trop longue, ils doivent la diviser en parties éventuellement indépendantes.

T pour Testable

La dernière lettre de l’acronyme INVEST représente testable. Cela signifie que la modification du Produit décrite dans la User Story doit être vérifiable et vérifiable. En d’autres termes, il doit être possible de vérifier si la solution mise en œuvre par les développeurs a apporté la valeur supposée à un Stakeholder spécifique.

Créer la meilleure User Story – résumé

INVEST est un acronyme qui décrit une User Story bien écrite. Elle doit être :

1. Indépendante des autres User Stories. Afin qu’elle puisse être modifiée ou supprimée du Product Backlog si nécessaire.
2. Négociable. Elle doit spécifier quoi faire en laissant le choix de la manière de le faire aux développeurs.
3. Précieuse, c’est-à-dire justifiant le sens commercial de la modification du Produit. Ou Verticale, c’est-à-dire présentant une nouvelle fonctionnalité du Produit visible par l’Utilisateur.
4. Estimable, c’est-à-dire ayant une taille et un critère d’achèvement définissables.
5. Petite suffisamment pour être complétée en une Sprint.
6. Testable afin qu’il soit possible de déterminer avec certitude qu’elle a été mise en œuvre.

Si vous aimez notre contenu, rejoignez notre communauté de petites abeilles sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.