User Stories et Use Cases (cas d’utilisation) sont deux façons très populaires de capturer les besoins utilisateurs (exigences fonctionnelles).
Toutes deux sont orientées BUT, plutôt centrées Utilisateurs, sont découvertes au cours d’ateliers de travail et peuvent être admirablement combinées avec les activités Expérience Utilisateur (Personas, Storyboard, Wireframe …)..
Cette question du choix entre les deux formalismes est récurrente parmi les équipes, et notamment côté Client (Métier ou Maîtrise d’ouvrage), même si je considère pour ma part que les User Stories sont plus appropriées dans la plupart des contextes, notamment Agiles.
Dans les deux cas, un vrai boulot d’accompagnement s’avère bien souvent nécessaire pour favoriser une bonne appropriation et une bonne utilisation sur la quotidien des projets.
Les deux formats se ressemblent mais ont aussi de réelles différences (déterminantes pour leur choix). Voici ces différences résumées dans un tableau:
Vous recherchez un coach agile d’entreprise disponible à Paris, Genève ou Lausanne pour vous accompagner dans la mise en place de l’agilité, Découvrez mon profil !
Merci pour ce tableau synthétique. Je me pose régulièrement la question de la différence entre les 2. Le Use Case est peut-être facilement assimiliable à la User Story selon le niveau de détail qu’on lui apporte (pré/post condition définies ou pas par ex).
Il y a toutefois 3 points où je ne suis pas tout à fait d’accord :
– point 3, j’aurais plutôt dit que la User Story peut être composée de plusieurs Use Cases… les Use Cases étant plus précis et considérant des contextes variables (déclencheur, conditions…) que la User Story n’aborde pas.
– la maintenabilité des Use Cases : il y a des outils de modélisations UML qui facilitent grandement la maintenance des Use Cases au cours de la vie du projet. Word, c’est pas top pour maintenir l’intégrité d’une doc projet… mais il n’y a souvent que ça à disposition.
– les tests : au niveau des User Stories, ce sont des tests d’acceptation qui devraient être rédigés par ceux qui définissent la User Story… ce ne sont pas les tests qu’un testeur (au sens professionnel du test) va définir et je ne suis pas sûr qu’il y ait une implication de testeurs à ce niveau. Par contre, un Use Case bien défini est un support de grande valeur ou le point d’entrée principal pour un testeur pour définir ses tests. Ce serait une erreur de ne pas impliquer le testeur, au moins durant les revues (s’il y a) même si un Use Case écrit selon les "normes" ne prévoit pas de "chapitre" test.
Hello Arnaud, merci pour ton commentaire.
Quelques élements de réponse sur les points que tu évoques:
– Point 3: je ne suis pas du tout d’accord avec toi, une user story ne peut pas inclure plusieurs ni même un use case. La taille d’une story est petite, c’est un critère de qualité. Ce qui pourrait correspondre à ce que tu décrits est plutôt une "Epic" (un format plus macro que la "User Story")
– Sur la question de la maintenabilité, j’irais effectivement dans ton sens mais comme tu le soulignes le format word est le plus utilisé…
– Sur la question des critères d’acceptation et le rôle des testeurs, je pense que nous devons vraiment changer les choses et aller dans une implication beaucoup plus forte des testeurs (que tu évoques) en tant que support du Product Owner sur la définition des critères d’acceptation et sur les élements de confirmation. Notre logique exprime surtout le cloisonnement de la partie Test et la séparation des testeurs du reste de l’équipe sur beaucoup de projets.
Je manque d’expérience sur les User Stories dans le pur style Agile et j’ai donc du mal à faire une distinction claire. Faudrait que je reparte à la recherche d’exemples si possibles comparatifs… ou alors si tu en as sous la main, je suis preneur 😉
Quant à la condition des testeurs, c’est un éternel problème mais qui tend, à mon avis, à s’améliorer, tout doucement (reconnaissance du métier, organismes comme le CFTL, de plus en plus d’offres de TRA de la part de SSII, une offre logiciel qui se développe…). Bref, ça c’est une autre histoire ;).
En tout cas, merci pour ce billet, ça me fait réfléchir et remettre en cause ce que je connais et crois comprendre 🙂
bonjour
bravo pour ce comparatif
c’est une question qui revient souvent sur le tapis au sein des projets
je suis globalement d’accord avec les différences présentées
j’insisterai sur l’aspect "liaison entre stories"
c’est parfois un probleme, surtout lorsqu’on est obligé de faire du "semi-agile", c’est-à-dire quand le product owner n’est pas suffisamment dispo pour l’équipe de dev et qu’on doit y palier par de l’écrit
dans ce cas, on enrichit les backlog avec des colonnes supplémentaires (thèmes engloblant, renvois etc)
il est vrai que les use cases sont plus structurants
personnellement je me sers de la notion uses cases pour expliquer les user stories à des PO qui ne connaissent pas, et de suite ca les aide à cerner la chose
Je vais maintenant me servir de ton tableau pour préciser les différences essentielles entre les deux approches
Cela dit, dans certains cas je pense qu’on peut remplir un backlog avec des UC de façon "agile", c-a-d sans forcément rentrer dans les détails écrits (l’esprit, pas la lettre)
Juste un petit commentaire pour dire qu’il me semble qu’il vaut mieux faire un rapprochement entre la liste des User Stories et le « Use Case Diagram » (et non entre un Use Case et un User Story)… Et en ce sens, je pense que le UC Diagram » est très intéressant car il donne une vue d’ensemble.