INVEST, le focus utilisateur
La grille d’analyse INVEST vous aide à évaluer le niveau de qualité de vos User Stories en 6 étapes. Simple, rapide et efficace !
Détail de la méthode :
I = Indépendante
Assurez-vous d’une part que votre US ne soit pas interchangeable avec une autre et d’autre part qu’elle puisse être implémentée à n’importe quel moment.
N’écrivez pas “créer une case login en vous assurant bien d’avoir déjà produit un espace de connexion pour les comptes-client ” mais plutôt “je dois pouvoir me connecter à un espace privé pour retrouver mes données”.
N = Négociable
Prenez en compte l’essentiel du besoin de votre utilisateur. Si vous rentrez trop dans le détail, vous risquez de découper votre fonctionnalité en détails techniques, perdant ainsi l’objectif premier d’un récit utilisateur. En effet, ce dernier sert à traduire un besoin utilisateur de manière simple et naturelle sans entrer dans un jargon technique afin qu’il “parle” à toutes les expertises dont l’équipe est composée et pas seulement aux développeurs.
N’écrivez pas “créer un fichier json de récupération des listes de produits puis catégoriser l’objet Produit afin de définir un tri spécifique sur l’objet TypeVetement pour qu’il soit sélectionné en Front” mais plutôt “je dois pouvoir faire mon shopping en sélectionnant des types de vêtements”
V = Valeur
Il faut que vos US mettent en avant la valeur du besoin client. Dans cette optique de “customer first”, il ne s’agit pas de lister des fonctionnalités techniques mais d’écrire des plus-values utilisateurs sous forme de mini-récits. Donnez de la valeur au besoin client avec chacune de vos stories.
N’écrivez pas “l’outil doit être en mesure de croiser des datas” mais plutôt “pour que mon expérience d’achat soit agréable je veux avoir un accès à un dressing personnalisé ”
E = Évaluée
Il s’agit ici d’ajuster le niveau de détail de votre US. Si elle est trop générale elle risque d’être trop vaste et de représenter une étape du projet à part entière et non un incrément implémentable.
N’écrivez pas “je veux pouvoir acheter un produit” mais plutôt “en tant que client , lors de la sélection d’un produit , je veux pouvoir synchroniser mon panier afin de passer une commande ”
S = Small
Restez simple et efficace, le détail sera créé par la suite. Ici, vous allez interroger le réalisme de votre US. Reprenez le contexte, elle doit être assez “petite” pour être réalisée dans une seule itération. Dès lors, elle doit correspondre à la capacité en temps et en compétences dont l’équipe dispose.
N’écrivez pas “je veux pouvoir payer mon produit sur la plateforme e-commerce et qu’il soit livré chez moi dans un court délai” mais plutôt “je veux pouvoir rentrer mon adresse de livraison avant de payer mon produit …”
T = Testable
Si votre US est de bonne qualité, elle doit exprimer de manière claire et précise des conséquences observables sur votre produit et le comportement utilisateur. Lorsqu’elle atteint ce niveau de clarté elle est testable.
N’écrivez pas : “chargement des pages rapide” mais plutôt “le chargement des pages ne doit pas excéder les 3 secondes”.
Chez Monsieur Guiz, nous utilisons cette méthode lors de nos backlog refinement. En effet, cette dernière est un bon moyen d’engager les équipes grâce à l’analyse des User Stories pré-écrites par le Product Owner. Non seulement chacun se fait une idée de l’ensemble du projet mais il y prend part à travers la discussion engagée.
Article qui pourrait vous intéresser
Découvrir la méthode MoSCoW et son application !