Agilité Back To Basics

User stories : un product backlog performant

Temps de lecture : 11 minutes

Back to Basics User Stories : faire un backlog performant !

Back to basics est une série d’articles dans laquelle nous allons revenir sur les fondamentaux, trop souvent oubliés des plateaux projet. Pour celles et ceux qui veulent rester agiles en toutes circonstances et ne pas perdre le fil, cette rubrique est faite pour vous !

Aujourd’hui, cap sur les User Stories, un des outils plébiscités par les agilistes pour optimiser la gestion des tâches.

Hier vous étiez Chef de projet digital et vous meniez un projet de bout en bout. Aujourd’hui, vous êtes Product Owner (PO) et la première mission qui vous est demandée est de rédiger des User Stories (US). Pourquoi ce changement ? Par où commencer ? Comment savoir si vos User Stories sont bien écrites ? Avant de vous expliquer comment les maîtriser efficacement, nous vous proposons de les définir.

Qu’est-ce qu’une User Story ?

Littéralement : récit utilisateur, scénario client, histoire de l’utilisateur, les User Stories sont l’unes des composantes utilisées dans les méthodes agiles.

Une User Story est la transposition écrite d’une fonctionnalité logicielle en version simplifiée, souvent adaptée à la taille d’un post-it ou d’une fiche cartonnée, qui décrit une exigence client.

De l’écriture des User Stories on retient deux avantages principaux :

  1. Agiliser le travail d’équipe en traduisant des fonctionnalités techniques en langage utilisateur. On ne s’adresse pas uniquement aux développeurs mais à tous les métiers impliqués dans le projet, grâce à l’utilisation d’un langage intelligible par tous.
  2. Optimiser et rationaliser le produit en le traduisant en un ensemble distinct de besoins client. Les fonctionnalités produit sont découpées en finalités utilisateur.

Bon à savoir

Si elles apparaissent pour la 1re fois dans le livre Extreme Programming Explained de Kent Beck, elles y sont décrites comme des briques dans la planification d’un projet. Désormais, elles sont considérées comme une pratique à part entière, indépendantes de l’Extreme Programming. Outre leur rôle technique, elles participent plus globalement à l’esprit agile du projet.

Dans un Mindset où il n’est plus question d’arriver d’un point A à un point B en fonction d’un cahier des charges inscrit dans le marbre, il faut redéfinir une base de travail. C’est ici qu’interviennent les User Stories, pendant contemporain de leur ancêtre, les fonctionnalités listées dans un cahier des charges. Plus de cahier des charges donc, mais une liste de tâches priorisées à accomplir qui constituent un backlog.

Tout ce qui se trouve dans votre backlog est communément appelé “items”. Les User Stories sont l’uns des items de votre product backlog au même titre que les Epics.

Ecrire des US sert avant tout à suivre le rythme d’évolution de votre produit en tenant compte des changements en cours de route, inhérents à tout projet. C’est ce qui va vous permettre de créer de la valeur produit plus efficacement !

Product Owner, l‘User Story doit devenir une de vos armes parmi les autres outils agiles (Lean Canvas, User Journey, Product Backlog, Road Map) pour s’adapter au changement et contrôler votre périmètre produit. Alors comment maîtriser les US à la perfection ?

Voici 6 étapes indispensables pour que vos User Stories deviennent de véritables outils de pilotage et ne soient pas de simples artifices.

Étape 1 : Identifier les besoins intrinsèques

Avant de commencer à rédiger vos User Stories, identifiez des besoins macro. Cela vous permettra de schématiser votre cible et ses besoins. Pensez au parcours de votre utilisateur et traduisez-le en flow de narration.

Comment faire ?

Premièrement, prenez du recul afin d’analyser l’expérience que va vivre l’utilisateur lors de son parcours. Ensuite, découpez cette expérience en un ensemble de besoins généralistes. Pour vous aider à identifier des besoins macro, n’hésitez pas à vous appuyer sur le concept de « Job to be done » de Clayton Christensen et d’Anthony Ulwick. Le premier illustre le concept en prenant l’exemple de la presse écrite. Si la mission principale d’un journal est de publier des actualités, il remplit également d’autres missions telles que diffuser des annonces de biens immobiliers, proposer des jeux pour divertir son lectorat etc. Ainsi, l’attente d’un client ne tient non pas dans l’expression d’un seul désir mais dans un environnement de besoins. En bref, les JTBD sont l’ensemble des missions à accomplir pour garantir la satisfaction client.

Pour réussir vos Jobs to be done : répondez aux 3 questions du livre « Value Proposition Design » de Yves Pigneur et Alex Osterwalder :

  • Quels sont les jobs que mes clients cherchent à accomplir ?
  • Quelles sont les frustrations que mes clients cherchent à éviter ?
  • Quels sont les bénéfices qui surprendraient agréablement mes clients ?

Une fois vos JTBD déterminés, écrivez-les respectivement sur un post-it et placez-les dans l’ordre le plus logique pour votre utilisateur. Ce faisant, vous avez mis en forme un flow de narration.

Vous remarquerez que ce flow de narration est valable aussi bien pour un site e-commerce que pour une boutique physique.

Une fois cette étape franchie, il est temps de rédiger vos User Stories !

Étape 2 : Rédiger les User Stories

Maintenant que vous avez votre flow de narration, vous pouvez passer de l’échelle macro à l’échelle micro. Pour chaque besoin identifié dans votre flow de narration, créez une liste de solutions pour leur apporter des éléments de réponse concrets.

Exemple :

  • Besoin : obtenir mon produit sélectionné ;
  • Solution : payer avec ma carte bleue ou payer avec une carte cadeau.

Une fois que vous avez découpé les JTBD en solutions, respectez le modèle d’écriture suivant :

  • Quand ___, (situation de mon utilisateur)
  • je veux ___, (motivation de mon utilisateur)
  • donc je peux ____. (résultat attendu de mon utilisateur)

“Quand j’ai fini ma sélection produit, je veux les obtenir donc je peux les payer et me les faire livrer.”

Concrètement que s’est-il passé ?

Nous avons affiné un besoin macro en le transformant en solution. Puis nous avons transposé cette solution en expression de besoin grâce au canevas d’écriture d’Alan Klement. Constat, nous avons créé un récit utilisateur : “quand j’ai fini ma sélection produit, je veux les obtenir donc je peux les payer et me les faire livrer.” Non seulement il est plus parlant et plus empathique que la solution générale exprimée initialement et d’autre part il a le mérite d’être compris et exploitable par tous les métiers – pas seulement les équipes techniques – impliqués dans le projet.

Une fois l’ensemble de vos User Stories rédigées, vous avez les éléments nécessaires pour constituer votre product backlog.

Étape 3 : Établir un ordre de priorité dans le product backlog

Ceci étant, l’erreur à ne pas commettre est de considérer chaque tâche à un niveau égal de priorité.
Ne pas prioriser soulève un inconvénient majeur : retrouver les mêmes conditions de travail qu’avec le cahier des charges du cycle en V. Afin de rendre votre travail plus flexible en créant de cycles courts et itératifs, classer les User Stories de votre backlog est un véritable enjeu.

La méthode MoSCoW

Pour déterminer l’ordre de traitement de vos User Stories, la méthode MoSCoW se révèle d’une efficacité redoutable. Méthode inventée par Dai Cregg, elle permet de fixer des échéances en fonction de l’évaluation du degré d’importance des tâches. Simple, rapide et intuitive, voici comment la mettre en place :

  • Le M  de Must : cette user story est vitale, nécessaire. Sans elle le produit n’est pas utilisable. Exemple : payer son panier.
  • Le S de  Should : cette user story est essentielle. Sans cette fonctionnalité je déçois ma cible. Exemple : la possibilité de choisir différents modes de livraison.
  • Le C de Could : cette user story est “surprenante”. Avec cette fonctionnalité, j’offre une expérience au dessus de ses attentes à mon utilisateur. Exemple : Des ventes flashs sur le site.
  • Le W de Won’t : cette user story n’apporte pas plus de satisfaction utilisateur. Exemple : un compteur de visiteur.

Une fois priorisées, il n’est pas encore temps de lancer le premier sprint, il faut désormais vous assurer de la qualité de vos US.

Étape 4 : Vérifier le niveau de qualité des US

Vérifier la pertinence de vos User Stories est primordial pour mener à bien le projet. Pour ce faire, vous pouvez les tester avec des grilles d’analyse dédiées. Elles vous aideront à déterminer le niveau de qualité de vos récits utilisateur.

3 grilles d’analyse pour vérifier la qualité de vos US

Vous pouvez utiliser les modèles suivants :

  • I.N.V.E.S.T. (Independent, Negotiable, Valuable, Estimable, Small, Testable);
  • S.M.A.R.T (Specific, Measurable, Achievable, Relevant Time-boxed) ;
  • T.R.E.S (Testable, Réaliste, Esthétique, Sensé)

Pour vérifier et ajuster la qualité de vos User Stories, ces grilles peuvent s’avérer efficaces mais pas suffisantes. Afin d’aller plus loin, nous vous conseillons de vous mettre à la place de l’utilisateur afin de capter l’expérience qu’il va vivre en utilisant le produit. Ne limitez pas vos récits utilisateurs à des séries d’actions à accomplir, brutes de contexte.
Cette vérification est l’ultime étape de travail en solo. Une fois vos User Stories écrites et testées, il faut les confronter à l’équipe.

Étape 5 : ajuster la granularité de vos récits

Dans l’optique de parfaire la vérification de la qualité d’une User Story, nous vous conseillons d’échanger avec l’équipe lors d’une cérémonie de Backlog Refinement Meeting. Durant ce rendez-vous, le Product Owner présente les User Stories à l’équipe de développement, l’occasion pour cette dernière de les interroger, parfois de les remettre en question. Autant d’éléments dont va se servir le Product Owner pour affiner les User Stories sélectionnées pour un sprint. Cette étape va vous permettre de faire un ultime tri dans vos User Stories en ajustant leur niveau de granularité. Ensemble, vous allez procéder à un “écrémage”.

Epics & US

En récoltant le feedback des uns et des autres, vous allez voir que certaines de vos User Stories n’étaient pas encore à la bonne échelle. Lorsque vous constatez qu’une user story est trop macro, il s’agit alors d’une Epic. Plus concrètement, avant de lancer une itération (cycle de 1 à 4 semaines), vous devez vous assurer que vos User Stories soient réalisables :

  • Par une personne
  • Dans une itération

Lorsque vos User Stories sont trop complexes pour correspondre à ces deux critères, ce sont des Epics. Vous devez alors les subdiviser en respectant les deux règles énoncées afin d’obtenir des User Stories.

Cette étape d’ajustement est primordiale pour deux raisons principales :

  1. Vous ajustez le niveau de réalisme des User Stories.
  2. Vous fédérez l’équipe dans un process de validation.

Lorsque vous débutez un projet avec une nouvelle équipe, nous vous conseillons de ne pas dépasser une moyenne de 4 User Stories par intervenant et par sprint.

Étape 6 : Ajouter les critères d’acceptation à une User Story

Lors du Backlog Refinement Meeting, votre dernière mission pour optimiser vos User Stories sera de définir en équipe les critères qui vous permettront de savoir si vous pouvez passer une user story en “done”. Pour ce faire, le plus simple est de se mettre d’accord, selon une grille de critères partagée et validée par toute l’équipe, sur les éléments qui permettent de savoir si une user story est correctement réalisée ou non. Autrement dit, vous allez définir des critères d’acceptation.

Pour définir au mieux vos critères d’acceptation, nous vous conseillons de tester les User Stories en utilisant le langage Gherkin :

  • Etant donné [un contexte initial (les acquis)]
  • Quand [un événement survient]
  • Alors [on s’assure de l’obtention de certains résultats]

Afin d’illustrer notre propos, reprenons le cas du moteur de recherche, pourvu d’un système d’autocomplétion, déjà évoqué lors de l’étape 3 :

  • Etant donné que je cherche une robe
  • Quand je tape « robe » dans ma barre de recherche interne
  • Alors un déroulant me propose « robe longue » et « robe à rayures »

Ces échanges vont permettre à votre équipe d’identifier les éléments nécessaires à la réalisation des User Stories. Lesquels sont autant de composants additionnels à joindre à l’User Story tels qu’un wireframe, une API, une maquette etc.

Et maintenant, à vous de jouer !

Notre point de vue

Chez Monsieur Guiz, nous avons la particularité de ne plus utiliser le canevas traditionnel des User Stories datant de 2001 – En tant que… / Je veux… / Afin de… – mais de lui préférer celui de 2013, établi par Alan Klement, le père des Job Stories.

Plutôt que d’opposer User Story et Job Story, nous considérons le deuxième comme l’évolution plus pragmatique et plus contemporain du premier.

De l’évolution des User Stories…

Les Job Stories, selon nous, permettent d’optimiser l’ancienne version. Notamment car elles donnent au contexte d’utilisation une place plus importante qu’à l’utilisateur en tant que facteur isolé.

… Et de leurs limites

Dans le canevas traditionnel d’écriture des User Stories datant de 2001 le désir de l’utilisateur est le moteur principal de la recherche.

Lorsque l’on isole le lien de cause à effet du “en tant que” alors “je veux”, l’analyse du besoin est, dans cette formulation, basée sur la subjectivité de l’individu utilisateur. Dès lors, il y aurait autant d’User Stories que d’individus. Diffcile alors de dégager des tendances et de trouver des KPI. Ainsi, L’hyper-personnalisation n’est pas toujours pertinente pour analyser un marché et une cible.

Attention à ne pas confondre besoin et goût

Un autre point mérite d’être relevé : la distinction entre les besoins et les goûts. Le besoin client ne doit pas être confondu avec le goût individuel. En tant que PO, c’est ce premier qui vous intéresse pour établir des fonctionnalités produit efficientes.

Dès lors, la méthode de 2013 permet de faire la part belle au contexte :

  • Quand ___, (situation de mon utilisateur)
  • je veux ___, (motivation de mon utilisateur)
  • donc je peux ____. (résultat attendu de mon utilisateur)

On reste dans une vision et une expérience focus utilisateur sans pour autant mettre de côté le contexte dans lequel il se trouve.

C’est bien dans l’interaction entre l’utilisateur et son environnement que l’on peut faire ressortir de manière efficace un besoin au sens marketing du terme.

Le mot de la fin

Le fait de s’interroger sur les meilleures façons de travailler sur un périmètre fluctuant, contribue à adopter une vision User Centric. En tant que PO, vous avez à coeur de mobiliser les équipes autour d’une vision commune et d’optimiser le produit. Les User Stories font partie des outils qui vous aide d’une part à utiliser un langage naturel utile pour fédérer une équipe multi-compétences et d’autre part à placer le client au coeur de la réflexion produit.

Dans un marché où l’évolution technologique et le changement ont une place prédominante, proposer des produits réalistes, adaptables et flexibles semble essentiel pour rester compétitif. Dans cette optique, la linéarité projet laisse naturellement place à un système de cycles itératifs, plus propice à l’innovation et au changement.Devenues l’outil de pilotage indispensable du Product Owner (PO) et porte-drapeau de la vision user centric, les User Stories sont un enjeu de taille dans la gestion de projet contemporaine.

Votre avis compte pour nous, alors n’attendez pas pour nous donner votre avis sur cet article !

À propos de Romain Le Bihan

Coach Lean Agile (consultant et formateur), certifié PSPO et SAFe, fervent défenseur de l'approche "Produit".

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.Les champs marqués par un * sont obligatoires *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.