Ce sujet pourrait paraître évident. En réalité, il ne l’est pas. Il y a, en fait, une grande incompréhension sur le terrain, de la définition de ce terme au regard de la théorie.
Revenons sur ce sujet avant d’avancer sur les spécifications et les tests.
Dans l’esprit des personnes qui ont initié le mouvement agile, les User Stories (US : Ken Beck – 1999) ont plusieurs particularités. Nous allons les détailler ci-dessous.
User Story et vue PO
Une User Story est le plus petit élément vu des Product Owners (PO). Ces derniers, représentants les métiers et les utilisateurs, doivent être capables d’aider à les spécifier et les tester (on pourra parler exactement de ce qu’on entend par “aider”).
Sur ce premier point, il faut noter que :
- la User Story est un récit utilisateur, donc une petite partie d’une fonctionnalité, qui sera à réaliser pour améliorer les histoires plus larges souhaitées par le PO (ce qu’on appelle une “epic” dans Scrum – épopée en français – ou une “feature” dans SAFe), elles-mêmes s’insérant souvent dans des histoires encore plus larges voulues par les métiers …
- Une “anomalie” (défaut de réalisation) ou un bug trouvé en production ne sont pas de nouvelles fonctionnalités, mais une correction de code erroné par rapport aux spécifications. Ils se différencient, par conséquent, d’une US.
- L’US est considérée par le PO, puisqu’elle représente un élément de réalisation pour les développeurs, matérialisé par un ticket. Mais, dans le cas où l’histoire englobante qui a été spécifiée ne peut être réalisée en un sprint, elle ne constitue pas le résultat attendu par l’utilisateur, seulement une partie. Celui-ci souhaite une épopée complète, pas un morceau …
User story et sprint
Ce type d’élément (artefact) agile est étroitement lié à la notion de “sprints”; Une user story s’insère dans un et un seul sprint. C’est donc un élément de planification pour les développeurs.
Comme les sprints en agile sont de durée limitée (de 2 à 4 semaines, sachant que plus ils sont courts, plus on est agile !), les US ne peuvent pas porter des évolutions complexes. Elles sont même, disons-le franchement, considérées parfois comme des “détails” pour les métiers. C’est la raison pour laquelle certains “end users” ne veulent pas en entendre parler et vouloir tester en continu en préférant attendre une fin de version (un groupement de 4 ou 5 sprints par exemple).
On ajoutera que les responsables IT de l’équipe agile (développeurs, business analysts) peuvent créer, toutefois, des “technical stories”. En effet, ils ont besoin de mettre en place parfois des solutions à vocation exclusivement technique, sans qu’un PO puisse leur affecter une valeur métier.
User Story et vue métier
Une User Story est liée à une “épopée” demandée par les métiers, au sens Scrum.
Rappelons qu’une épopée (epic) est une fonctionnalité du système dans un parcours utilisateur spécifique. Autrement dit l’épopée répond à un besoin dans un “cas d’usage” du système (ex: créer un client Français), voire parfois à plusieurs cas d’usage (par exemple, s’authentifier, qui est générique à tous les cas d’usage).
Une épopée est, en général, de taille bien supérieure à une US pour plusieurs raisons :
- Elle ne tient pas compte des efforts d’implémentation mais uniquement de la tâche (ensemble d’actions de l’opérateur) qui apportera de la valeur à l’utilisateur
- Elle permet une discussion sur les US à intégrer. En effet, Ron Jeffries accorde une importance particulière à la négociation et la validation, entre PO et le reste de l’équipe agile, sur le contenu des US (règle des 3C – 2001).
Une User Story est donc un élément de réalisation d’une épopée qui peut être développée et testée en un sprint. C’est à la fois un support à l’expression d’un besoin et un élément de planification agile.
User Story et construction de la solution
L’US se traduit typiquement par un ordre de réalisation. Ce dernier se matérialise par un Post’It ou un ticket dans un outil tel JIRA.
Une épopée “simple” peut être déjà une US. Il y aura donc à lui créer un ticket de type US pour le développeur. Mais il y aura aussi un autre ticket réservé à l’epic correspondante (pour être homogène avec les épopées plus complexes).
Une épopée est, en général, d’une taille nécessitant un “affinage” en plusieurs US (les techniques à adopter sont multiples, hors de notre sujet d’étude), et donc ne pourra être réalisée qu’en plusieurs sprints.
User Story et documentation
Une User Story est un support à la communication et doit être documentée a minima. C’est essentiel pour que le développeur puisse bien réaliser son travail. Pour autant :
- Une fois terminée … l’US est fermée, oubliée !
- Sa taille étant limitée, certains préconisent une feuille A4 pour la décrire. Cela peut paraître parfois trop peu (il y a du textuel, ne serait-ce que pour présenter et comprendre l’US …), mais 2 pages devraient être un maximum.
Dans cette documentation éphémère, popularisée par Mike Cohn, il faut distinguer notamment :
– Le libellé de l’US qui suit un “gabarit” standard :
En tant que <utilisateur(s)>
Je veux pouvoir <action à faire commençant pas un verbe à l’infinitif>
Afin de <objectif poursuivi et justifiant l’US>
– Son contenu et, en particulier, les “critères d’acceptation” qui serviront à développer et à tester l’US.
Critères caractérisant une User Story
Une User Story doit être INVEST (Bill Wake – 2003), c’est-à-dire :
- Indépendante,
- Négociable,
- porteuse d’une Valeur métier,
- Estimable en termes d’effort de réalisation, en considérant la mesure comme un indicateur relatif. Sans entrer dans le détail, on peut, par exemple, la classer dans une suite de Fibonacci (une estimation en points de 1, 2, 3, 5, 8, 13),
- Suffisamment petite, puisqu’elle doit tenir dans un sprint,
- Testable.
Nous allons reprendre dans le prochain article ces 6 points et voir les difficultés rencontrées sur le terrain.
L’auteur
Didier JOLIOT, Ingénieur Coach agile et formateur
Didier a une grande expérience professionnelle : développeur puis responsable qualité et certification de logiciels temps réels critiques. Ex : Airbus (A320, A340), missiles, spatial, nucléaire, sous-marins, … Il a été ensuite expert spécifications et tests auprès d’équipes MOE, puis de MOA bancaires. Il a été aussi directeur de projet, et enfin expert auprès des managers pour la stratégie des SI (« Portfolio Management » et architecture d’entreprise).
Il pratique depuis 2012 l’agilité. Il a été coach agile pour le Product management de très gros projets « agiles à l’échelle » au Crédit Agricole et à la Société Générale, et pour de nombreuses équipes Scrum.
Il a écrit 5 livres et de nombreux articles. Il enseigne, depuis des années, dans plusieurs écoles d’ingénieur et dans les entreprises. Il a créé, de plus, plusieurs méthodes : le langage « Business Modeling Language (BML) », l’algorithme ATDD des tamis successifs, la CNV-A, etc.
La taverne du testeur 
Publié par