Une user story est une phrase simple permettant de décrire avec suffisamment de précision le contenu d’une fonctionnalité à développer. C’est l’une des briques essentielles qui permet de recueillir le besoin utilisateur. Après avoir expliqué dans le premier épisode ce qu’était l’agilité au sens SCRUM, nous allons aujourd’hui aborder un certain nombre d’erreurs rencontrées autour de celle-ci.
User Story : manque de clarté sur le public cible utilisant la fonctionnalité
La user story (US) doit répondre à ces 3 questions :
- Quoi faire ?
- Pourquoi ?
- Pour qui ?
Le format commun de la description d’une fonctionnalité au travers d’une user story suit un énoncé du type :
En tant que “tel type d’utilisateur”, je voudrais “telle fonctionnalité” afin de pouvoir “réaliser telle action”.
Ce format est utilisé car une user story doit décrire simplement et de manière compréhensible une fonctionnalité à valeur métier du système développé. De plus, ce format permet de répondre aux 3 questions citées plus haut.
Ainsi présentée et constituée, la user story permet de décrire un besoin utilisateur plutôt que de détailler une approche technique ou système. Elle se focalise sur l’un des aspects de l’Agilité : apporter de la valeur métier ajoutée plutôt que de la valeur purement technique.
Exemple de formulation d’une user story :
En tant que client, je veux pouvoir me connecter au site de ma banque pour accéder et contrôler mes comptes.
L’une des erreurs courante est de ne pas spécifier le type d’utilisateur précisément. Il est aisément compréhensible qu’en fonction de sa nature, ou de son degré de privilège pour un utilisateur, une même fonctionnalité peut être déclinée différemment en raison de besoins et d’habilitations différents. Pour chaque type rôle ou du type d’utilisateur, il convient de spécifier une US.
Recommandation :
Toujours garder en tête à qui l’on s’adresse et à quel type d’utilisateur la US est dédiée.
La User Story définit le « comment »?
Une User Story ne doit pas s’attarder sur le « comment faire ? ». Cette question n’est volontairement pas adressée de façon à laisser la personne en charge du développement la latitude nécessaire à la réalisation de la fonctionnalité. Cela laisse au développeur le libre choix de son implémentation.
Recommandation :
Le PO ou les parties prenantes ne devraient pas donner trop de direction technique dans les US et laisser cette part d’autonomie à l’équipe de développement. Généralement, cette autonomie permet une plus grande implication et responsabilisation de l’équipe, ce qui est bénéfique à l’ensemble du projet.
Omission du “pourquoi ?” dans la user story
Il arrive également qu’en se focalisant sur la fonctionnalité, la US contienne bien les deux éléments « pour qui ? » et « quoi faire ? », mais que le « pourquoi ? » soit omis. Bien que n’étant pas indispensable à la réalisation de la fonctionnalité, le « pourquoi » est important car il explique à l’équipe de développement le contexte du besoin. Il lui permet également à terme une meilleure connaissance globale du produit. Ce « pourquoi ? » permet d’expliquer l’apport en valeur de cette US. Et cette information est très utile dans la priorisation des tâches à effectuer lors du sprint planning.
Recommandation :
Ne pas négliger la partie « pourquoi ? » lors de la rédaction de la US.
Considérer qu’une user story est figée
Une US est généralement rédigée par le PO. Elle est issue d’un besoin métier qui va être affiné au fil du temps et des ateliers de rédaction des US pour prendre sa forme qui sera embarquée par la suite dans un sprint. S’arrêter sur une version d’une US et ne pas vouloir la changer peut être contre-productif et opposé au principe d’accueillir la nouveauté.. Tant que la US n’est pas embarrée dans un sprint, elle doit pouvoir subir des changements.
Recommandations :
Les user story doivent répondre à un certain nombre de critères que l’on regroupe dans l’acronyme INVEST :
- Indépendantes les unes des autres, au moins durant le sprint en cours. Une US doit pouvoir être développée sans nécessité qu’une autre ne le soit avant ou après elle. Il ne doit pas y avoir de contrainte de précédence dans les US d’un sprint donné. Cela permet de fluidifier le flux de travail de l’équipe de développement.
- Négociable : la US ne constitue pas un contrat ferme et définitif entre les utilisateurs et l’équipe de développement. Mais elle doit laisser la possibilité à la discussion et la négociation tant qu’elle n’est pas incluse dans un sprint.
- Ayant de la Valeur, chaque US doit avoir un réel intérêt et une réelle « valeur métier » ou pour les clients. Cela implique un bon découpage de chaque US ce qui apporte de la valeur à celle-ci. L’image souvent utilisée est celle du gâteau à plusieurs couches. Personne veut d’une part de gâteau découpée horizontalement, on souhaite plutôt une part (même petite) qui contienne l’ensemble de la composition.
- Estimable : pour qu’une US soit estimable, elle doit être avant tout compréhensible par les développeurs afin qu’il l’évalue et que le client puisse prioriser ses demandes par la suite.
- Small : petite autant que possible entre l’estimable et le testable pour fluidifier un maximum le flux de travail car un item petit présente toujours moins d’incompréhension et d’incertitude pour sa réalisation qu’un grand item.
- Testable : ce que l’on entend par testable signifie que l’on ait suffisamment compris les enjeux et la valeur apportée par la US pour pouvoir la rendre testable. Cela implique des effets et comportements observables une fois développée.
C’est le caractère négociable donc collaboratif de la user story qui permet une tolérance et une marge de manœuvre afin de ne pas figer dans le marbre cette dernière.
De plus, le format synthétique de la user story dans sa description laisse volontairement, du moins dans un 1er temps, les détails de la fonctionnalité de côté. Ce sont eux qui pourront être discutés et affinés par la suite, en fonction du degré de compréhension des développeurs en charge de la user story.
