Consulter l’article d’introduction sur l’agilité dans les projets informatiques.
Dans le paradigme de l’agilité, les besoins exprimés par les directions sont formalisés via des Stories agiles.
Une « story » décrit une fonction du produit et la valeur métier associée à ce produit (= le besoin à couvrir). A partir de cela, le Product Owner détaille les caractéristiques associées à cette story (chemins alternatifs, conditions, cas d’erreur, …).
Pour d’assurer qu’Une user Story est bien formulée du point de vue agile et intégrable dans une itération, il existe plusieurs critères à considérer. La méthode INVEST décrit les 6 critères pour évaluer la qualité de la story : Indépendant / Négociable / Valeur ajoutée / Estimable / « Sized appropriately » / Testable.
INVEST : I comme Indépendant
Chaque Story doit :
- Être étanche,
- Produire de la valeur indépendamment des autres stories,
- Apporter un Retour Sur Investissement (ROI).
INVEST : N comme Négociable
Chacune des stories peut être remise en question et discutée durant le projet. Elle doit être facilement compréhensible par tous les acteurs du projet.
INVEST : V comme « Valuable » (à valeur ajoutée)
Chaque story apporte de la valeur ajoutée.
INVEST : E comme Estimable
A partir de la story, l’équipe de développement peut estimer la charge de développement nécessaire et esquisser globalement la solution technique pour répondre au besoin.
INVEST : S comme « Sized appropriately »
La story doit être la plus unitaire possible.
INVEST : T comme Testable
Chaque cas doit être validé par les directions métiers via des tests si possible pour s’ancrer un maximum dans la réalité du processus.
Conclusion
L’élaboration des user stories ne se résume pas à rédiger un cahier des charges mais doit répondre à certaines exigences afin que les phases d’itération soient les plus pertinentes possibles et alignées avec la démarche agile. A noter cependant que la démarche agile doit s’adapter aux spécificités de l’organisation afin de ne pas apporter trop de rigidité au projet.
