Guide de mêlée | 20. INVEST – Créer la meilleure User Story

INVEST est une méthode pour créer de bonnes User Stories. Cela permet de vérifier s'ils ont un contenu correctement formulé et s'ils se rapportent à la valeur commerciale du Produit. Et aussi, si leur taille et leur convivialité 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. Sommaire

Introduction

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

• Indépendant
• Négociable
• De valeur
• Estimable
• Petit
• Testable

Nous avons écrit plus sur ce qu'est la 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 en corrélation avec d'autres User Stories. Bien sûr, ce ne sera pas une indépendance totale. Vous ne pouvez pas diviser la création de produits en modules complètement séparés. Cependant, il est crucial de se souvenir de garder les User Stories aussi indépendantes que possible. Grâce à cela, même si l'un d'eux n'entre pas dans la phase de mise en œuvre ou est significativement modifié, le reste n'aura pas à être modifié. 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'il définit l'objectif, pas le chemin pour y arriver.

En d'autres termes, il définit une fonctionnalité attendue du Produit, et non une solution technique à mettre en œuvre.

La négociation des 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 dit « Quoi » faire. Les Développeurs sont chargés 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 :

• De valeur
• Vertical

Les deux révèlent les caractéristiques clés d'une bonne User Story. Par conséquent, nous avons décidé d'expliquer ce que chacun d'eux signifie.

De valeur

Une User Story précieuse justifie l'objectif commercial de la modification. En d'autres termes, il répond avec précision à la question de savoir pourquoi introduire la modification et pourquoi elle est importante du point de vue des parties prenantes.

Vertical

La deuxième caractéristique; Vertical dérive de la méthodologie Agile. La User Story verticale contient une nouvelle fonctionnalité du Produit visible par l'Utilisateur. C'est-à-dire qu'il ne se concentre pas sur « l'amélioration des performances » horizontale dans une couche sélectionnée du Produit. Au contraire, cela lui ajoute une autre « couche ».

En d'autres termes, la User Story décrit comment modifier le fonctionnement global d'un Produit en répondant à la question Quoi 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'il doit clairement définir le périmètre 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 les efforts nécessaires pour le terminer.

La portée et la difficulté d'une tâche sont généralement estimées en unités appelées Story Points. Ils sont relatifs. Et chaque équipe de développement calcule la valeur du Story Point dans la pratique en se basant sur l'expérience précédente.

Dans des articles séparés, nous avons couvert plus d'informations 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 qu'il ne devrait pas y avoir plus d'un Sprint. Si les Développeurs découvrent lors du Sprint Planning que la User Story proposée par le Product Owner est trop longue, ils doivent la scinder en parties éventuellement indépendantes.

T pour testable

La dernière lettre de l'acronyme INVEST signifie testable. Cela signifie que la modification du Produit décrite dans la User Story doit tenir la route et être vérifiable. En d'autres termes, il devrait être possible de vérifier si la solution mise en œuvre par les développeurs a fourni la valeur supposée à une partie prenante spécifique.

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

INVEST est un acronyme qui décrit une User Story bien écrite. Ça devrait être:

1. Indépendamment des autres User Stories. Afin qu'il puisse être modifié ou supprimé du Product Backlog si besoin est.
2. Négociable. Il devrait spécifier ce qu'il faut faire en laissant le choix de la façon de le faire aux développeurs.
3. Valable , c'est-à-dire justifiant le sens commercial de la modification du Produit. Ou Vertical, 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. Assez petit pour être complété en un seul Sprint.
6. Testable afin qu'il puisse être déterminé avec certitude qu'il a été mis en œuvre.

Si vous aimez notre contenu, rejoignez notre communauté d'abeilles occupées sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Auteur : Caroline Becker

En tant que chef de projet, Caroline est 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 la pression du temps font d'elle la meilleure personne pour concrétiser des projets complexes.

Afficher tous les articles

Guide de mêlée :

1. Glossaire des termes, rôles et notions de base
2. Qu'est-ce que Scrum ?
3. Valeurs Scrum
4. Comment implémenter Scrum dans votre entreprise ?
5. Scrum Team - qu'est-ce que c'est et comment ça marche ?
6. Qui est un Product Owner ?
7. Les erreurs les plus courantes du Product Owner
8. Qui est le Scrum Master ?
9. Caractéristiques d'un bon Scrum Master
10. Les erreurs les plus courantes du Scrum Master
11. Quelles statistiques et métriques le Scrum Master doit-il suivre ?
12. Coopération entre Product Owner et Scrum Master
13. Équipe de développement dans Scrum
14. Les erreurs les plus courantes des développeurs
15. Artefacts Scrum
16. Mise à l'échelle Scrum
17. Carnet de sprint
18. Qu'est-ce que le carnet de produit ?
19. Qu'est-ce qu'une User Story ?
20. Créer la meilleure User Story avec INVEST
21. Les erreurs les plus courantes de la User Story
22. Critères d'acceptation des user stories
23. Estimation et Story Points dans Scrum
24. Planification Poker
25. Jeu d'estimation d'équipe
26. Définition de l'incrément
27. Événements Scrum
28. Qu'est-ce que Sprint dans Scrum ?
29. Engagements de l'équipe Scrum - Objectif du produit, objectif du sprint et définition de l'achèvement
30. Qu'est-ce qu'un Burndown Chart ?
31. Comment créer et interpréter un burndown chart ?
32. Avantages et inconvénients du burndown chart
33. Tableaux Kanban dans Scrum et Scrumban
34. Velocity in Scrum - Vitesse de l'équipe de développement
35. Mêlée quotidienne
36. Planification des sprints
37. Revue de sprint
38. Qu'est-ce qu'une rétrospective Sprint ?
39. Erreurs courantes lors d'une rétrospective de sprint
40. Nourrir le backlog produit