La User Story n’est pas juste une nouvelle formulation de spécification, un morceau de texte écrit sur post-it ni le découpage de la spécification en petits morceaux. La User Story est une nouvelle philosophie d’expression des demandes fonctionnelles.

La User Story n’est pas un outil de spécification mais un outil de conversation

Le point de départ d’une User Story est l’expression d’un besoin client et non d’une solution fonctionnelle (« J’ai besoin d’accéder au service » plutôt que « J’ai besoin de cliquer sur un bouton »)

L’objectif est de créer le dialogue avec l’équipe de développement afin de trouver une solution commune pour le PO et l’équipe : « la solution trouvée est pertinente pour le client et au coût le plus faible possible pour l’équipe ».

Après vous être assuré que le besoin de l’utilisateur est partagé et compris, vous pourrez enrichir votre User Story avec plus de détails. Tâchez cependant de ne jamais perdre de vue le besoin.

En tant que [rôle utilisateur/segment utilisateur/persona]
Je veux [effet levier/besoin]
Afin de [impact/bénéfice du levier/élément de valeur pour l’utilisateur]

Exemple :
En tant que commercial
Je veux identifier un véhicule à partir de son immatriculation
Afin de retrouver rapidement le véhicule que je cherche

Ce format permet d’exposer le besoin du point de vue de l’utilisateur. L’agilité est une démarche orientée utilisateur qui permet de s’assurer que tous les développements du produit seront utiles, utilisables et utilisées.

Les parties « En tant que » et « Afin de » sont à la main du Product Owner, elles doivent être comprises par l’équipe et n’ont pas de raison d’être remises en question par l’équipe. Le rôle du Product Owner est de comprendre le contexte et le besoin des utilisateurs, il dispose de fait de plus de connaissance métier que l’équipe de développement. Il est important que l’équipe fasse confiance au Product Owner sur ces parties.

Cependant la partie « Je veux » est une zone de discussion entre l’équipe et le PO. Il est possible que le service à rendre, imaginé par le PO ne soit pas le plus pertinent au regard de l’impact attendu. Il est tout aussi possible que l’équipe, avec sa connaissance de l’existant dans le produit et de la faisabilité technique, ait en tête une proposition plus appropriée et moins chère.

​​​​​​​Vous pouvez amener avec le temps des éléments de précisions du besoin et de la demande.

Vous pouvez par exemple :

• Décrire le contexte
• Ajouter des maquettes (ayant été au préalable discutée avec l’équipe de développement pour valider leur faisabilité technique)
• Décrire où se situera la fonctionnalité (ex : dans la rubrique véhicule)
• Formaliser ce qui sera visible de l’utilisateur

La User Story n’est normalement pas un espace de spécification technique. La technique est discutée par l’équipe de développement durant sa phase de conception et développement. Ecrire de la technique dans la User Story peut avoir deux impacts :

• Si la technique arrive en amont des échanges avec l’équipe de développement (au sens de toute l’équipe et pas seulement de représentants experts), la partie “Conversation” sera perdue.
• Spécifier techniquement signifie que la personne qui fait le développement n’est pas celle qui a conçu le développement. Préférez le développement en binôme ou le conseil et la discussion durant le développement au fait de spécifier par écrit.

La User Story n’est pas une documentation, c’est un élément périssable qui n’a de durée de vie que jusque la demande soit développée. Si vous souhaitez documenter, faites-le dans des outils prévus pour.

La User Story peut être enrichie de deux manières différentes :

• Par le Product Owner : Le Product Owner a la charge de préciser ce qui ne peut émerger d’une discussion avec l’équipe de développement, que seul le Product Owner grâce aux parties prenantes (utilisateurs, référents utilisateurs, UX designer…) peuvent identifier
• Par la discussion entre le Product Owner et l’équipe de développement : Il est fondamental, comme nous l’avons vu plus haut, d’enrichir l’US à partir des échanges menés avec l’équipe de développement. Notamment pour trouver une solution technico-fonctionnelle adaptée.

Dans une User Story, on appelle cet enrichissement « Critère d’acceptance », c’est-à-dire : tout ce qui permettra à l’équipe et au Product Owner de valider que la User Story est bien terminée, que la demande a été comblée.

Les critères d’acceptance peuvent-être :

• Des règles de gestion métier identifié par le Product Owner
• Des recommandations UX
• La charte graphique
• Les jeux de données

Les critères d’acceptance peuvent être associés à des tests d’acceptance permettant à l’équipe de développement de vérifier que son livrable est conforme.
Le test d’acceptance décrit :

• La situation, le contexte initial
• L’action effectuée
• Le résultat attendu

Le formalisme « Sachant que… », « Lorsque… », « Alors… » est un bon moyen d’écrire ces tests

Exemple :

En tant qu’utilisateur
Sachant que je suis sur le configurateur de prix
Lorsque je renseigne un montant négatif
Alors j’ai le message d’erreur « Montant erroné » qui apparaît

Sachant que je suis sur la page de sélection de l’offre
Lorsque je renseigne les différentes informations fiscales de mon client et que j’appuie sur « Choisir l’offre »
Alors je suis redirigé vers la page de l’offre la plus adaptée

Independante : Une User Story doit pouvoir être indépendante des autres leur permettant d’être développées dans n’importe quel ordre, nous offrant plus de flexibilité en cas d’imprévu.

Négociable : Dans la continuité de la notion de « Conversation », la notion de « Négociable » signifie que la solution a été discutée et qu’un consensus a été trouvé entre la demande fonctionnelle et la faisabilité technique

Valorisée : La User Story doit fournir de la valeur aux utilisateurs, aux usagers de la fonction décrite par la User Story.

Estimable : La User Story doit être suffisamment comprise par tous pour pouvoir estimer un coût de production

Sizée (De la bonne taille) : Une User Story doit aller la plus faible granularité possible. C’est à dire le plus petit élément qui apporte de la valeur aux utilisateurs ou d’apprendre rapidement collectivement. Par exemple, en Scrum on va chercher à terminer plusieurs stories dans un sprint. Aussi, plus une User Story est petite plus elle est facile à estimer. Plus elle est grosse, plus il y a de complexité et d’inconnu diminuant la fiabilité de l’estimation

Testable : Correspondance avec la notion de « Confirmation ». La User Story doit porter en elle les critères de validation. L’écriture des tests au plus tôt permet de mieux comprendre le comportement demandé et les critères de « Terminé » fournissant un cadre à l’équipe pour le développement

Exemples

En tant qu’utilisateur
Je veux transformer mon expérience
Afin de mieux appréhender l’outil

Ceci n’est pas une bonne User Story car :

• Difficilement estimable
• Beaucoup trop grosse et complexe
• Pas de notion de testabilité

En tant qu’utilisateur
Je veux ajouter des clients et visualiser une liste de clients et les filtrer par les critères suivants (N° client, nom, prénom, Lieu de résidence) et les trier par ordre croissant.
Afin de gérer mon client

Ceci n’est pas une bonne User Story car :

• Pas indépendante car plusieurs demande au sein de l’US. Il sera nécessaire de la découper afin de désolidariser la fonction d’ajout, sa visualisation et le tri (potentiellement plusieurs User Stories de tri par type de donnée). En découpant je peux commencer par la visualisation avant même de faire la création.
• La demande est déjà très précise la rendant peu négociable. Le fait de justifier la demande par « Afin de gérer mon client » est trop générique pour permettre de questionner la demande de création, listing, filtre etc

En tant qu’utilisateur
Je veux trouver mes clients par N° client
Afin de les retrouver facilement car le N° client est une information de référence chez nous

Ceci est une bonne User Story car :

• C’est une fonction indépendante qui peut être développée à n’importe quel moment (même sans outil de création de client et l’intégration de données de test car elle permettra de vérifier que l’information est retrouvée facilement)
• Elle est négociable car elle laisse la place à la discussion afin de voir quelle est la solution la plus appropriée d’un point de vue solution/coût. Une bonne pratique pour savoir si votre “je veux… afin de…” est bien écrit, essayez de remplacer le je veux… que vous avez écrit par le “afin de”, si la phrase fonctionne, gardez ce “je veux” et trouvez un autre “afin de”
• Elle est valorisable, nous pouvons estimer la valeur que peut avoir cette fonctionnalité pour le client
• Elle est Estimable à condition que les critères de recherche ne soient pas trop nombreux et complexes
• Elle a la bonne taille à condition que les critères de recherche ne soient pas trop nombreux et complexes
• Elle est testable : « J’entre un N° de contrat et il apparaît en sortie »