Le mnémonique INVEST pour les projets de développement logiciel Agile a été créé par Bill Wake pour rappeler les caractéristiques d’un Product Backlog Item ou PBI de bonne qualité. Les PBI peuvent être utilisés dans un backlog Scrum, un tableau Kanban ou un projet XP. Ces éléments s’appellent User Story INVEST.
Ces critères de User Story INVEST permettent de juger de la qualité d’une User Story. Ils conduiront éventuellement, par itération successive, à reformuler l’énoncé (le cas nominal), voire à modifier en profondeur la Story en réécrivant ses critères d’acceptation.
Signification de l’acronyme agile INVEST
L’acronyme INVEST signifie :
- I pour Independante : chaque User Story doit être indépendante des autres,
- N pour Negociable : les détails composant la User Story doivent être négociables. C’est pour cela qu’on écrit une User Story en une seule petite phrase afin de ne pas forcer les détails,
- V pour Valuable : chaque user story doit apporter de la valeur business pour les métiers, les utilisateurs ou les clients,
- E pour Estimable : l’effort de réalisation de chaque User Story doit être estimable par l’équipe qui la réalise,
- S pour Small : la User Story doit être suffisamment petite pour être terminée dans un sprint,
- T pour Testable : la User Story doit pouvoir être testée seule.
Cette définition seule n’est suffisamment explicite pour être correctement comprise et appliqué. Entrons dans le détail de chaque point de cette définition pour clarifier l’usage et le bénéfice.
User story Indépendante
Être indépendante pour une User Story signifie qu’elle doit pouvoir être implémentée avant ou après n’importe quelle autre. C’est, de mon point de vue, le point le plus délicat de la User Story INVEST. L’axe pris pour découper des User Stories est souvent fonctionnel. Par exemple faire la création de comptes avant l’authentification. Dans cet exemple il est évident que sortir le produit sans ces deux User Stories n’aurait pas beaucoup de sens pour le métier. Cependant, dans la backlog, les deux peuvent être décorrélés. Il est possible de développer l’authentification avant le formulaire de création de comptes (pour cela les équipes utilisent la pratique de bouchonnage).
Trop souvent les User Stories dans les projets en entreprise sont découpées sous forme de séquence (développer la page avec le formulaire, développer le traitement, développer la base de données). Ce découpage n’est pas bon, une User Story pour qu’elle puisse être indépendante, doit couvrir toutes les dimensions de la fonctionnalité qu’elle permet de réaliser (on en reparle plus bas pour le Valuable).
À noter que pour pouvoir découper efficacement vos User Stories, vous devrez avoir de vraies équipes agiles, dans le sens où elles doivent avoir toutes les compétences pour réaliser leur backlog dans son intégralité.
Bien découper ses User Stories aide à prioriser et à estimer si elles sont bien indépendantes les unes des autres.
User story négociable
Une bonne User Story capture l’essence, formulez-les simplement afin de ne garder que l’objectif fonctionnel attendu. Utilisez toujours des mots simples, dite-vous qu’un enfant de 10 ans pourrait comprendre le contenu de votre User Story.
Vous pourrez compléter vos User Stories avec des règles de gestions, le tout étant qu’elles restent facilement compréhensibles par l’équipe agile et le métier (voir le client). Une User Story n’est pas un contrat, c’est une histoire qui contient de la valeur métier.
Elle est négociable pendant toute la phase d’affinage, elle évolue au fil du temps pour réduire l’incertitude et clarifier le besoin.
User story valuable
Définir la valeur d’une User Story permet de montrer le bénéfice pour l’utilisateur ou le client une fois qu’elle sera réalisée. Ce point est parfois difficile à comprendre. Les User Stories sont toujours fonctionnelles. Elles portent toujours de la valeur métier, c’est pour cela que nous utilisons généralement la formalisation “En tant que XXX, je veux XXX, afin de XXX”.
Rien ne vous interdit d’écrire des tâches techniques dans votre User Story ou de mettre dans votre backlog des éléments techniques. Simplement ces éléments techniques de votre backlog ne devraient pas avoir le même formalisme que vos User Stories pour éviter la confusion.
Je vois parfois des “En tant que directeur technique, je veux que la base de données soit MYSQL…” Cela n’a aucune valeur pour les utilisateurs de votre produit. Mettez toujours un Personae dans votre cas nominal, si vous mettez un rôle opérationnel (ici le Directeur Technique) c’est systématiquement incorrect. Si vous n’avez pas de Personae défini pour votre produit, prenez un peu de temps pour les identifier, cela vous aidera beaucoup dans la conception de votre produit et vos priorisations.
Il existe différentes techniques pour qualifier la valeur métier. Le meilleur moyen selon moi est de qualifier cette valeur avec vos utilisateurs/clients grâce au business value canvas. Cette technique, couplée au Business model canvas, est redoutable d’efficacité pour qualifier et clarifier les attentes de vos utilisateurs et clients.
User story estimable
Chaque User Story doit être suffisamment claire et comprise par l’équipe pour qu’elle puisse estimer l’effort de réalisation. Il existe plusieurs techniques d’estimation pour les écrire. Je vous invite à lire l’article dédié à l’estimation qui aborde le sujet de ne plus estimer en jours-homme.
User story suffisamment petite
Les méthodes agiles servent à casser l’effet tunnel bien connu des cycles en V. Pour casser cet effet, les User Stories doivent être suffisamment petites pour être réalisées, testées et démontrées sur un sprint. La durée des Sprints est variable d’une équipe à l’autre. La durée moyenne constatée est de 3 semaines.
Les équipes agiles peuvent réaliser plusieurs User Stories par Sprint. Le plus important étant qu’elles terminent celles sur lesquelles elles se sont engagées au début du Sprint.
User story testable
Intégrer des cas de tests dans vos User Stories pour maximiser la valeur livrée. Ils vous assurerons que ce qui sera développé correspond bien à vos attentes. Ces cas permettront aux développeurs de réaliser précisément la User Story INVEST en se basant sur le comportement attendu. Ensuite, elle pourra être testée par une tierce personne qui suivra les cas de tests. Dans certains cas vous pourrez même automatiser ces cas de test. Et ainsi automatiser vos tests de non-régression.
Un bénéfice indirect d’avoir des cas de test dans vos User Stories est que vous créez mécaniquement une documentation fonctionnelle. Vous pourrez utiliser cette documentation pour accueillir de nouveaux développeurs dans l’équipe par exemple. Elle sera très utile aussi lorsque vous aurez des BUGs à corriger.
En conclusion
À présent vous en savez plus sur la User Story INVEST. Cette technique, comme beaucoup d’autres, prend du temps à mettre en place, et nécessite de bien former et accompagner vos équipes pour qu’elles puissent tirer pleinement parti de ses bienfaits.