La façon dont les besoins du Metier sont exprimés en terme de story agile est déterminante pour maximiser le gain d’efficacité promise par les projets agiles.

Qu’est ce qu ‘une story

C ‘est une paragraphe court qui decrit sommairement une fonction du produit et sa valeur métier, par exemple :

En tant que client je peut chercher les produits de la e-boutiques en tapant des mots clés cela me permet de trouver rapidement l'ensemble des produits qui repondent à mes besoins.

Une user story est censée être un sujet de discussions et non pas une description détaillée d’une fonction. Il n ‘y a pas de mal à ce que une story soit au départ trops générique voir mal cernée par le product owner lui même tant qu ‘elle reste dans le backlog. Cependant, elle ne peut être admise dans une itération que quand le product owner a la maturité nécessaire pour pouvoir donner des informations detaillées : sur la fonction principale, les chemins alternatifs, les cas d ‘erreur… (Voir cet article sur les critères de réalisation d’une story)

Les 6 critères de qualité INVEST

Afin de s ‘assurer qu ‘une user story a les qualités nécessaires pour être effectivement incluse dans une itération, 6 critères ont été definis sous l’acronyme INVEST.

• Independant : chaque story doit constituer un avantage métier par elle même : On ne peux pas avoir deux story qui dépendent l ‘une de l ‘autre pour produire de la valeurs. Exemple:

  Story 1: en tant que client mes transactions doivent être stockée en base lors d 'un achat. 
  Story 2: en tant que client je doit recevoir une fois par mois une liste détaillée de transactions pour pouvoir mettre à jour ma comptabilité.
  

  La story 1 ne produit pas de valeur en soit, imaginons qu ‘elle soit réalisée lors d ‘une iteration, il n’y aura de vrai ROI (retour sur investissement) qu’appartir du moment ou la Story 2 est mise en place. Entre temps, du temps de développement a été investi sans réelle rentabilité. Par ailleurs, dans un environnement changeant, la story 2 pourra devenir à un certain moment inutile ou pas prioritaire, on aura alors investit du temps inutilement.

• Negociable : Toute story peut être remise en question, discutée négociée à tout moment. Par ailleurs, elle doit être exprimée dans un language compris à la fois par l’équipe de développement et le métier pour permettre une réelle négociation et connaissance des enjeux partagée.

• Valuable : Chaque story doit apporter de la valeur, c’est la base du bon sens. Si on est incapable de décrire le bénéfice utilisateur d’une story, c’est qu’elle est probablement supérflue ou plus proche d’une tache technique que d’une story. Les besoins non fonctionnels sont des fois assez astucieux à exprimer en terme de valeur métier. Ainsi, mettre en place des logs techniques peut s’expriemer :

  En tant qu'opérateur de maintenance je doit avoir accès à des traces d'erreur afin de rapidement résoudre les incidents qui bloquent les utilisateurs.
  

• Estimable : Litérallement, cela veut dire que l’équipe de développement peut donner une estimation de l’effort pour réaliser la story. Plus concrètement, il s’agit de s’assurer que l’équipe a une discussion autour de la story et voit globalement la solution technique pour la réaliser.

• Sized appropriately : Doit avoir une taille la plus petite possible. Afin de réduire la taille d’une story une des techniques est de découper en variante ainsi :

  En tant qu'utilisateur, je peux payer mes achats en ligne afin de recevoir ma commande plus rapidement.
  

  On pourrait découper cette story en 3 :

  En tant qu'utilisateur, je peux payer mes achats en ligne par carte banquaire afin de recevoir ma commande plus rapidement.
  En tant qu'utilisateur, je peux payer mes achats en ligne avec mon compte paypal afin de recevoir ma commande plus rapidement.
  En tant qu'utilisateur, je peux payer mes achats en ligne avec mon compte mobile afin de recevoir ma commande plus rapidement.
  

• Testable : Chaque story développée doit pouvoir être validée par le métier en effectuant des tests. Il faut donc qu’elle soit définie de façon concrète avec des critères d’acceptation précis.

En conclusion

Le découpage en story n’est pas juste une façon différente de produire un cahier des charges mais a un impact réel sur la conception du produit lui même et le déroulé du projet. C’est ce bon découpage qui donne tout son intérêt à un projet agile:
– La motivation des équipe augmente en voyant l’aboutissement concret de ce qu’elles réalisent sans être bloquées par le métier.
– La satisfaction des managers augmente en voyant à chaque itération des fonctions utiles livrées et améliorées et donc un ROI progressif.

Et enfin, le métier garde la marge de manoeure pour ajuster ou re-prioriser les fonctions du produit et gérer les risques et incertitudes de l’évolution du contexte.