Qu'est-ce qu'une User Story ?

Lorsque l'on parle de méthodologie Agile, le sujet des "User Stories" (ou récits utilisateurs en français) est incontournable, et pourtant la définition ou l'utilisation qui en est faite ne correspond pas toujours au concept d'origine.

Si vous n'êtes pas familier avec l'Agile, nous avons traité le sujet dans un précédent article

L'origine

En 1998, lors de la visite d'un projet de transformation numérique chez Chrysler, Alistair Cockburn, l'un des pères fondateurs du mouvement Agile lance la phrase suivante : "A user story is a promise for a conversation."

En français, cela donnerait : "Un récit utilisateur est l'annonce (ou l'invitation, la promesse)  d'une discussion."

En 1999, Kent Beck introduit (entre autres) le concept de "User Story" en pratique pour la gestion de projet dans son ouvrage "Extreme Programming Explained", et au fil des années le concept ne cessera d'évoluer et des bonnes pratiques verront le jour à force d'expérience.

L'idée reçue

Si vous demandez à un développeur pris au hasard de vous décrire le concept d'un récit utilisateur, il y a de fortes chances pour que la réponse soit à peu près :

"C'est la description textuelle d'une fonctionnalité logicielle du point de vue d'un utilisateur, souvent 1 à 2 lignes sur un post-it."

Et si il y a une part de vérité sous cette description, c'est un peu comme la partie visible de l'iceberg, car en n'utilisant les User Stories que sous la forme d'une simple carte (ou d'un post-it), on perd une grosse partie de la raison d'être de ces dernières.

La vraie nature des User Stories

Une "User Story" est un outil qui permet de définir une exigence logicielle en fonction de trois données importantes :  "Qui ?", "Quoi ?" et "Pourquoi ?", ou autrement dit :

• Qui est l'utilisateur qui va effectuer cette action ?
• Qu'est-ce qu'il va pouvoir faire
• Quel bénéfice cette action va-t'elle lui rapporter (à lui ou à un autre utilisateur)

Mais le concept ne s'arrête pas là, comme le disait Alistair Cockburn, une User Story doit "inviter à la discussion" et c'est là le concept important qui diffère des anciens outils de suivi de projets.

En décrivant (trop) précisemment en amont une fonctionnalité devant être réalisée, cela ferme la possibilité de (re)discuter de la tâche, à la fois avec les différents corps de métier (développeur, architecte, UI designer,...) mais aussi avec le client.

En réalité on se donne une fausse idée de certitude en essayant de tout prévoir (ce qui est impossible, un projet vie et évolue même pendant le développement), en fixant à la fois le but (la fonctionnalité) mais aussi souvent le chemin pour y arriver (l'implémentation).

L'idée derrière une User Story est de définir simplement le contexte et le but, mais de laisser l'implémentation libre à la discussion de chacun des corps de métier.

Cela permet à la fois de solliciter la créativité de tous les corps de métiers pour améliorer cette implémentation, mais aussi de pouvoir réagir plus facilement en cas de changement dans l'orientation du projet.

Mais comment faire pour être sûr d'y arriver, tout en gardant le projet cohérent ? Et bien grâce cadre de travail présenté juste après !

Le framework des 3C

Ce framework décompose la création d'une User Story en trois grandes parties, chacune commençant par la lettre C : la Carte, la Conversation et la Confirmation.

La Carte

La carte est la partie la plus connue de la création d'une US, et c'est malheureusement parfois la seule dont les gens se souviennent.

Cette étape consiste à rédiger en langage naturel (10 à 15 mots), une exigence logicielle sous la forme d'une fonctionnalité du point de vue de l'utilisateur final, sous la forme suivante :

"[UTILISATEUR] [ACTION] [BENEFICE]"

Exemple : "En tant que vendeur, je souhaite poster une photo de mon article pour améliorer mes chances de ventes"

Cette phrase va servir à la fois de description courte, mais aussi plus ou moins d'identifiant lorsque l'on aura besoin d'évoquer cette User Story en particulier.

La Conversation

On l'a dit, c'est le gros élément différenciant par rapport à d'autres méthodes de gestions de tâches plus classique, la partie discussion d'une User Story doit avoir une place importante et doit, dans l'idéal, rassembler au maximum :

• Les échanges avec le client allant même jusqu'à prendre des citations ou extraits de conversations
• Les échanges avec les différents corps de métiers en interne
• Les fichiers, ressources et un maximum de documents traitant de l'US en question

Je tiens à rappeler que ce n'est pas seulement au Product Owner, Scrum Master ou au chef de projet de participer à la conversation, il faut que cette espace pousse à la discussion toutes les branches travaillant sur le projet !

Car une discussion tout seul, ce n'est pas une discussion...

La Confirmation

Cette partie doit contenir toutes les spécifications requises par le client pour valider que le récit utilisateur réalisé correspond bien aux exigences.

L'équipe projet peut aussi ajouter des éléments de confirmation en fonction des exigences qualités internes afin que la fonctionnalité soit validée lorsqu'elle est parfaitement fonctionnelle et que l'implémentation soit de qualité.

C'est en s'appuyant sur tous les éléments présents dans la partie confirmation de chaque User Story que le Product Owner pourra définir si cette dernière est définitivement validée, ou si elle doit repartir en développement.

Le cycle de vie

En pratique, on retrouve souvent 6 états différents pour une même User Story, lesquels sont :

• En attente (Pending)
• En discussion (Discussing)
• À faire (To-Do)
• En développement (Developing)
• En confirmation (Confirming)
• Terminée (Finished)

Bonnes pratiques

Il existe un moyen mnémotechnique afin de se rappeler d'un certain nombre de bonnes pratiques lors de la rédaction des récits utilisateurs, cette astuce est l'acronyme suivant : INVEST.

I pour Independent

Une US devrait pouvoir être déployée sans dépendre d'un autre récit utilisateur.

N pour Negotiable

L'idéal est de ne cadrer que l'essentiel du besoin utilisateur afin de laisser un maximum d'espace à la discussion.

V pour Valuable

Une US doit délivrer une valeur pour l'utilisateur finale, sinon elle doit être remise en question.

E pour Estimable

Une estimation doit pouvoir être réalisée afin de pouvoir être priorisée et logée dans un sprint.

S pour Small

Une US doit être suffisamment courte à réaliser pour être complétée en quelques jours. Si cette dernière dure plusieurs semaines ou mois, il est nécessaire de la diviser en plusieurs US plus courtes.

T pour Testable

Elle doit être testable grâce aux critères de confirmation établis lors de la rédaction de cette dernière.

Avantages

Les avantages d'une bonne utilisation des User Stories dans la gestion de projets sont entre autres :

• de s'assurer de garder l'attention fixée sur les utilisateurs en premier
• de favoriser la collaboration entre les différents corps de métiers lors de la phase de communication
• de pousser la recherche de solutions créatives pour l'équipe afin de gagner en temps de développement et en qualité
• de maximiser l'inertie en gardant des récits utilisateurs suffisamment courts et motivants pour les développeurs

J'espère que cet grâce à cet article vous y voyez un peu plus clair sur les User Stories et que vous pourrez les mettre en place plus facilement dans votre gestion de projet.