Méthode INVEST : évaluer une user story
Voyons maintenant la méthode "INVEST".
Cette méthode va nous aider à vérifier la qualité d'une User Story.
Il s'agit d'un acronyme pour :
Indépendante, Négociable, Valeur, Estimable, Suffisamment petite (ou Small), Testable.
À la lecture d'une User Story, on pourra donc se passer cet acronyme dans la tête afin d'évaluer l'User Story que l'on a devant les yeux.
I comme Indépendante
Une User Story doit pouvoir se suffire à elle-même.
Elle devrait pouvoir être développée sans affecter d'autres User Stories.
N comme Négociable
Au départ, une User Story est rédigée sans détail, dans un langage simple.
Elle contient l'essentiel, les détails seront ajoutés ensuite, au fur et à mesure, lors des Backlog refinement par exemple.
On négocie donc le périmètre de la User Story dans un deuxième temps.
V comme Valeur
Ma User Story apporte-t-elle de la valeur au client ?
Toute User Story doit être utile et apporter de la valeur au client.
L'User Story n'est pas le lieu pour les besoins techniques uniquement, car cela n'impacte pas directement le client.
Pour toute évolution technique, on pourra s'assigner une tache technique, mais on ne créera pas d'User Story dédiée.
Par exemple, "Créer la base de données des produits" ne sera pas une User Story.
Mais ce pourrait être une tache de la User Story "En tant que client, je souhaite voir la liste des produits disponibles pour pouvoir les sélectionner".
E comme Estimable
Suis-je en mesure d'estimer l'effort que va me demander l'User Story.
Même si on ne parle pas forcément d'estimation très précise, il faut pouvoir avoir une idée de l'effort à fournir pour réaliser l'User Story.
Si j'en suis incapable, c'est que l'User Story n'est pas suffisamment claire et qu'il reste des ambiguïtés.
Au cours de cette formation, nous verrons des méthodes pour nous aider à faire ces estimations.
S comme Suffisamment petite (ou Small)
Une User Story ne doit pas être une fonctionnalité trop large.
Il ne faut pas oublier que les durées de sprint sont limitées.
Il faut donc faire en sorte de découper suffisamment les fonctionnalités en sous-fonctionnalités si besoin, afin que l'on puisse réaliser le développement de l'User Story dans le sprint.
Si c'est impossible, il faut revoir le découpage des fonctionnalités et les scinder en plusieurs User Stories si nécessaire.
T comme Testable
Puis-je savoir précisément comment je vais pouvoir tester ma User Story ?
Si on ne sait pas comment la tester, c'est encore une fois parce que l'User Story n'est pas assez claire et nécessite d'être revue.