De quoi s'agit-il?

La grille des critères INVEST permet de juger de la qualité d'une User Story; elle conduira éventuellement à reformuler son énoncé, voire à modifier en profondeur la Story (ce qui se traduit souvent physiquement: on déchire la fiche ou le Post-It correspondant et on en écrit une autre). Une bonne User Story est:

• Indépendante des autres

• Négociable initialement, plutôt qu'un engagement ferme

• Verticale, ou ayant de la valeur en soit

• Evaluée en termes de complexité relative

• Suffisamment petite (en anglais Small)

• Testable en principe, ce qu'on vérifie en écrivant un test

Plus en détail, une bonne User Story:

• Pour répondre au critère I, doit pouvoir être implémentée avant ou après n'importe quelle autre; une erreur classique étant par exemple d'argumenter que "la Story sur la prise de commande implique d'avoir ouvert un compte, donc il faut réaliser en premier celle concernant l'identification (login) de l'acheteur". C'est un peu comme supposer qu'on ne peut écrire le chapitre 2 d'un roman qu'après avoir achevé le chapitre 1: plus facile, mais avec un peu d'imagination on arrive très bien à inverser cette séquence. Dans notre exemple l'équipe de développement mettra en place les "bouchons" nécessaires pour simuler un utilisateur identifié.

• Pour répondre au critère N, ne formuler dans un premier temps que l'essentiel, à savoir l'objectif fonctionnel recherché; on évitera par exemple de spécifier dans une User Story des éléments techniques, par exemple "En tant qu'acheteur, lorsque j'écris dans le champ texte puis que je clique sur le bouton Recherche, la liste à gauche du champ de recherche est renseignée avec les articles correspondants". Ces détails d'implémentation feront l'objet d'une discussion permettant d'identifier la meilleure solution; initialement, une formulation du type "L'acheteur peut chercher des articles par mot-clé" est suffisante pour l'estimation et la planification.

• Pour répondre au critère V, représenter un incrément réellement utile pour l'utilisateur final ou du point de vue du client. Par exemple, "réaliser le schéma de la base de données pour la facturation" n'est pas un incrément ayant de la valeur en soi, mais une tâche technique. A contrario, "émettre une facture pour les achats d'articles en France" en laissant pour plus tard une seconde Story dont l'énoncé serait "émettre une facture pour des achats livrés depuis l'étranger" représente un meilleur découpage: chaque incrément permet de réaliser une partie distincte du chiffre d'affaires.

• Pour répondre au critère E, être suffisamment comprise, mais également suffisamment précise. Il arrive parfois qu'on formule des User Stories qui représentent presque un projet à part entière, par exemple "Optimiser le calendrier de livraison des achats". Les conditions de satisfaction doivent être suffisamment précises et restreintes pour que l'équipe de développement puisse quantifier l'effort d'implémentation, sinon dans l'absolu du moins en termes de complexité relative. (L'équipe estime par exemple que "Livrer en deux fois lorsque des écarts supérieurs à une semaine séparent les dates de livraison de deux articles du panier" représente deux fois l'effort requis pour "Emettre la facture", cette dernière servant en quelque sorte d'étalon.)

• Pour répondre au critère S, ne pas dépasser quelques jours-hommes. La granularité exacte est fonction du nombre de personnes dans l'équipe de développement et de la durée de l'itération, le critère déterminant étant la possibilité de terminer au minimum une, et idéalement cinq ou six au minimum, User Stories dans une seule itération.

• Pour répondre au critère T, être suffisamment bien comprise pour qu'il soit possible de fournir un exemple détaillé: "Lorsque j'achète l'article X au prix Y, sachant que la TVA sur la catégorie Livres est de Z, la facture doit indiquer le montant total suivant:..." La fonctionnalité envisagée doit entraîner de la part du produit des conséquences ou des comportements observables. Ainsi "Améliorer la performance" n'est pas une bonne User Story, il est préférable de préciser: "La page contenant les résultats de recherche doit s'afficher en moins de 2 secondes".