Categories: BlogGuide Scrum

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.

Caroline Becker

En tant que chef de projet, Caroline est une experte dans la recherche de nouvelles méthodes pour concevoir les meilleurs flux de travail et optimiser les processus. Ses compétences organisationnelles et sa capacité à travailler sous pression font d'elle la meilleure personne pour transformer des projets compliqués en réalité.

View all posts →

Caroline Becker

En tant que chef de projet, Caroline est une experte dans la recherche de nouvelles méthodes pour concevoir les meilleurs flux de travail et optimiser les processus. Ses compétences organisationnelles et sa capacité à travailler sous pression font d'elle la meilleure personne pour transformer des projets compliqués en réalité.

Share
Published by
Caroline Becker

Recent Posts

Le rôle de l’IA dans la modération de contenu | IA dans les affaires #129

Les entreprises luttent pour gérer une vaste quantité de contenu publié en ligne, des publications…

3 days ago

Analyse de sentiment avec l’IA. Comment cela aide-t-il à provoquer des changements dans les entreprises ? | IA dans les affaires #128

À l'ère de la transformation numérique, les entreprises ont accès à une quantité sans précédent…

3 days ago

Meilleurs outils de transcription IA. Comment transformer de longs enregistrements en résumés concis ? | IA dans les affaires #127

Saviez-vous que vous pouvez obtenir l'essence d'un enregistrement de plusieurs heures d'une réunion ou d'une…

3 days ago

Génération de vidéos par IA. Nouveaux horizons dans la production de contenu vidéo pour les entreprises | IA dans les affaires #126

Imaginez un monde où votre entreprise peut créer des vidéos engageantes et personnalisées pour n'importe…

3 days ago

LLMOps, ou comment gérer efficacement les modèles de langage dans une organisation | IA en affaires #125

Pour tirer pleinement parti du potentiel des grands modèles de langage (LLMs), les entreprises doivent…

3 days ago

Automatisation ou augmentation ? Deux approches de l’IA dans une entreprise | IA en affaires #124

En 2018, Unilever avait déjà entrepris un voyage conscient pour équilibrer les capacités d'automatisation et…

3 days ago