Rédiger des user stories efficaces pour une production sans histoires !

En tant que lecteur de ce blog, je souhaite en savoir plus sur les user stories, afin de mieux collaborer avec mon équipe de production / mon Product Owner / mon client.

Requête acceptée !

Pour répondre à votre besoin, nous vous proposons la fonctionnalité « article » pour définir ensemble ce qu’est une user story, expliquer son intérêt et ses usages et vous donner quelques conseils pour bien les rédiger. Qu’en pensez-vous ?

Une user story décrit un besoin fonctionnel selon le point de vue du ou des utilisateurs finaux d’un produit digital. Il s’agit d’un artefact extrait de la méthode Agile Scrum, qui permet de s’assurer que la solution développée présente bien une certaine valeur ajoutée pour les utilisateurs.

Rédigée dans un langage courant, elle contextualise le besoin pour l’équipe de développement. Elle s’appuie sur le format suivant : « En tant que [profil client], je souhaite [objectif de la fonctionnalité] afin de [résultat] ».

Une user story sert un triple objectif :

• Elle permet de valider l’adéquation entre le besoin utilisateur et la solution envisagée pour y répondre.
• Elle aide les équipes de développement à mieux comprendre la demande des clients. Ainsi, ils peuvent devenir force de proposition dans le projet, et suggérer plusieurs options pour atteindre l’objectif défini.
• Enfin, elle permet à toutes les parties prenantes de comprendre l’utilité d’une fonctionnalité ou d’une tâche pour le produit. Cela permet à tous de déterminer la priorité à lui donner dans le développement.

Ainsi, les user stories facilitent les discussions sur le produit, à la fois au sein de l’équipe de développement et avec les parties prenantes externes, en recentrant les débats sur un seul dénominateur commun : l’utilisateur final.

Dans la majorité des cas, c’est le Product Owner qui rédige les user stories. Néanmoins, l’exercice de découpage d’un Product Backlog en User stories est un travail d’équipe. Le Product Owner ajuste sa rédaction en fonction des retours de l’équipe de production et des autres parties prenantes, afin que la user story présente une vision fidèle du produit à développer.

I pour Independent

La user story doit être la plus indépendante (ou autonome) possible pour faciliter son développement. L’indépendance des user stories les unes par rapport aux autres permet à plusieurs développeurs de travailler sur une même fonctionnalité en même temps, sans devoir attendre que l’un ait terminé son travail pour que l’autre puisse commencer le sien.

N pour Negotiable

Tant qu’elle n’a pas migré dans un Sprint Backlog, une User Story peut être challengée, modifiée, ou ajustée. Cela permet, par exemple, de reporter les impacts d’un test utilisateur suite à une livraison sur tout le projet sans perturber le rythme de production ou les délais de livraison.

V pour Valuable

La User Story doit apporter de la valeur ajoutée à l’utilisateur final. À ce titre, il est important de bien spécifier quel est l’utilisateur final dans la user story pour que l’équipe puisse déterminer son intérêt, et la prioriser ou non. N’oubliez pas que derrière le mot « utilisateur final » d’un même produit digital, on peut y trouver l’administrateur qui gèrera les contenus, le développeur qui fera des mises à jours de maintenance ou bien un client. Et tous n’ont pas les mêmes attentes face à votre produit.

E pour Estimable

L’équipe de développement doit pouvoir donner une estimation de l’effort requis pour réaliser une user story. Cela permet entre autres de définir correctement la priorité de la user story et de vérifier qu’elle peut être terminée au cours du sprint. À ce titre, les user stories passent souvent par une phase de Backlog grooming pour gagner en précision, jusqu’à leur estimation et leur intégration dans un Sprint.

S pour Small

Plus l’Epic aura été découpée, plus les User Stories qui s’y rattachent seront “petites” et plus elles seront simples à développer, tester et déployer.

T pour Testable

Des critères objectifs de tests doivent être mis en place pour chaque user story, afin de permettre à l’équipe d’évaluer la conformité du développement réalisé. Il s’agit de l’incontournable « definition of done » ou critères d’acceptation, qui permettent à toutes les parties prenantes de valider une livraison et de clôturer la user story dans le Product Backlog.

Il est important de garder à l’esprit que la user story est un outil de travail qui va intéresser toutes les parties prenantes tout au long du projet. Partant de ce principe, voici quelques conseils pour créer des user stories qui feront progresser le projet.

1. Qui, quoi pourquoi

Une user story doit éclairer ces trois points pour que personne ne perde de vue l’objectif du produit digital. C’est d’ailleurs pour cela qu’on structure la rédaction d’une user story en 3 parties, selon le schéma « en tant que / je veux / afin de ». Autrement dit, pour rédiger une bonne user story, il faut au préalable avoir une réponse complète aux trois questions suivantes :

• quelles sont les caractéristiques de l’utilisateur final ?
• quel est le besoin réel de l’utilisateur final ?
• quel est l’objectif de la fonctionnalité décrite pour l’expérience de l’utilisateur final ?

Exemple : « en tant que client (qui), je souhaite accéder au suivi de ma commande (quoi) afin de m’assurer d’être présent au moment de la livraison (pourquoi). »

2. Une user story doit susciter la conversation

Une user story doit ouvrir la réflexion auprès de toutes les parties prenantes sur une problématique utilisateur. Le but est de trouver la solution adéquate pour l’utilisateur final, en se détachant au maximum de ses a priori ou ses « réflexes métiers ». Si la user story annonce une solution dès le départ, ce n’est plus une user story, mais une ligne d’un cahier des charges.

Mauvais exemple : « En tant qu’administrateur de plateforme, je souhaite uploader une liste de contacts clients avec le protocole XXX afin d’envoyer une newsletter. »

Bon exemple : « En tant qu’administrateur de plateforme, je souhaite uploader mes listes de contacts clients afin d’envoyer une newsletter ».

3. Ajustez le niveau de détail

Une user story gagne en précision au fur et à mesure que le projet progresse. Cela implique deux choses :

• d’une part, il est rare d’avoir une user story complète et prête à être développée d’emblée ;
• d’autre part, l’intitulé de la user story seul ne suffit pas pour qu’elle soit intégrée dans un Sprint Backlog.

Bien souvent, le Product Owner va ajouter des éléments annexes à la user story pour permettre à l’équipe de production de développer la fonctionnalité correspondante. Ces éléments peuvent être des règles métiers, des wireframes ou des maquettes d’interface, les critères d’acceptation, des données… Le niveau de détails à ajouter à la user story doit être discuté au préalable avec l’équipe de production, et maintenu pour toutes les user stories du projet.

• Une user story est une phrase simple décrivant un besoin fonctionnel, écrite du point de vue du ou des utilisateurs finaux.
• Pour évaluer la qualité d’une user story, il est recommandé d’utiliser les critères INVEST.
• Une user story est un outil de travail collaboratif. Elle doit être comprise, ajustée et validée par toutes les parties prenantes avant d’être mise en production.