Comme un peintre a ses toiles, ses pinceaux et ses tubes de couleur, tout Product Manager a son backlog, ses EPICs et ses user stories. C’est son matériel de travail, ce qui va lui permettre de créer.
Le backlog est non seulement utile à l’équipe Produit, qui se réfère à son contenu pour prendre connaissance des solutions à développer mais également aux autres équipes, tech, métiers, qui peuvent le consulter pour avoir de la visibilité sur les sujets en cours et à venir.
En tant que Product Manager, vous êtes responsable de sa création et de sa gestion.
Alors, permettez-nous de vous présenter dans ce long article le backlog Produit sous tous les angles : ses formes variées, ses différents composants. Nous vous présentons aussi les rituels d’équipe qui vont le faire vivre et enfin nos conseils de pros pour transformer votre toile en oeuvre digne de Léonard de Vinci !
Attention, c’est sérieux et aride. Mais vous en sortirez plus savante ou savant !
Qu’est-ce qu’un backlog ?
Avant de vous présenter nos conseils pour construire et maintenir un backlog, repartons du point de départ. Un backlog Produit, quezako ?
Un backlog Produit est un ensemble ordonné de tâches à réaliser pour délivrer le produit. Il permet non seulement d’avoir une vision globale sur ce qui constituera le produit mais également de préparer le développement de manière incrémentale et itérative.
Souvent présenté sous forme de liste, on retrouve en tête du backlog les éléments apportant une forte valeur ajoutée. Ces éléments sont petits et détaillés pour pouvoir livrer le plus rapidement possible des incréments de valeur. En redescendant dans la liste, la priorité sera moindre et les éléments plus gros, moins détaillés.
.png?width=540&name=image%20(5).png)
Parle-t-on du ou des backlogs ?
Le backlog est un outil de travail que l’on peut utiliser à n’importe quel niveau du process produit. Vous pouvez donc avoir différents types de backlog. Nous avons évidemment évoqué plus haut le backlog Produit, qui sert de socle au développement du produit mais il en existe d’autres. Par exemple, si vous souhaitez organiser les retours utilisateurs et les demandes d’évolutions, vous pourrez créer un backlog d’opportunités. Il contiendra des problèmes à résoudre.
Pour optimiser les fonctionnalités existantes, un backlog d’expérimentations vous permettra de gérer les tests à mener. Votre backlog sera alors constitué d’informations bien définies sur les hypothèses retenues, les tests à réaliser pour valider ou non ces hypothèses et les résultats attendus.
Dans le framework Scrum, le backlog Produit se décline en sprint backlog. **Ce dernier est une partie du backlog Produit qui permet de s’accorder sur les éléments à développer durant le prochain sprint. Les éléments du sprint backlog sont choisis pour répondre à un objectif de sprint défini.
-1.png?width=1914&name=Untitled%20(1)-1.png)
Enfin, si votre équipe souhaite porter une attention particulière à la gestion de la dette technique, elle pourra créer un debt backlog (👉 pour aller plus loin sur la dette technique).
Le backlog peut donc se décliner à tous les niveaux, à vous de définir vos propres règles et de choisir si vous souhaitez un seul backlog contenant tous les éléments Produit ou plusieurs backlogs.
Les éléments d’un backlog Produit
Les composants principaux d’un backlog
Maintenant que vous connaissez les différents types de backlogs, recentrons nous sur le backlog produit.
Un backlog produit est composé de divers éléments, dont les plus communs sont les Epics, les User Stories, les enablers (ou tâches techniques) et les anomalies (ou bugs). Vous les utiliserez probablement tout au long de votre vie de Product Manager, quel que soit le produit sur lequel vous travaillez et quelle que soit l’organisation dans laquelle vous vous trouvez.
Les Epics
Une Epic (ou "épopée" en Français) est une brique fonctionnelle représentant un besoin utilisateur de haut niveau.
L'Epic sert à matérialiser dans le backlog un besoin fonctionnel identifié et estimable par les équipes de développement de manière macroscopique (en taille de T-shirt par exemple : taille S M, L). Cela permet d'avoir une approximation de la complexité d'un sujet afin de le prioriser.
Par la suite, à travers les activités d’affinage que nous verrons plus bas, l’Epic peut être découpée en plus petits éléments appelés User Stories. Par exemple, une Epic “gestion du panier client” pour un site d’e-commerce peut se décomposer en plusieurs stories : “Ajouter un produit au panier”, “Modifier la quantité d’un produit au panier” “Supprimer un produit du panier” etc.
-1.png?width=762&name=Untitled%20(2)-1.png)
Les User Stories
Une User Story (“récit utilisateur” en français) est la description fonctionnelle utilisée dans les méthodes agiles. L'objectif est de spécifier le développement d’une fonctionnalité. Elle doit exprimer à qui elle s’adresse et en quoi elle apporte de la valeur.
La User Story définit le besoin utilisateur selon une structure qui permet d’exprimer de manière atomique, systématique et claire l’intérêt de la fonctionnalité.
Généralement, une User Story se compose :
- D’un titre, exprimant la finalité de la User Story (ex : Supprimer un article du panier)
- D’une phrase narrative orientée utilisateur décrivant le bénéfice souhaité, souvent structurée sous la forme “en tant que ... je veux ... afin de ...” ou bien “Lorsque... l’utilisateur peut... afin de...” (ex : En tant qu’utilisateur, je souhaite supprimer un article de mon panier, afin de commander uniquement les produits dont j’ai besoin)
- D’un ensemble d’exigences et de critères d’acceptation, détaillant les tests et conditions nécessaires à la validation de la fonctionnalité.
-1.png?width=1037&name=Untitled%20(3)-1.png)
Cette structure générique vous servira de base à la rédaction de vos User Stories. Vous viendrez ensuite les compléter en ajoutant les éléments pertinents à la compréhension du besoin et de la solution : maquettes, schéma d’architecture, spécification de tracking, éléments de contexte...
Le framework INVEST vous donnera une ligne de conduite pour rédiger le contenu de vos User Stories. Ses six critères vous permettrons de vous questionner pour rédiger de bonnes User Stories.
💡 Zoom sur le framework INVEST pour bien rédiger vos User Stories
I – Indépendante : elle doit se suffire à elle-même, car les dépendances avec d’autres User Stories induisent des problématiques de testabilité et de planification.
N – Négociable : elle doit amener à la discussion et peut-être modifiée jusqu’à son inclusion dans une itération.
V – Valeur : elle doit apporter de la valeur à l’utilisateur final. La notion de valeur étant toujours difficile à évaluer, la User Story doit être exprimée avec une vision de l’objectif recherché pour l’utilisateur.
E – Estimable : elle doit être suffisamment claire et comprise par l’équipe pour que celle-ci soit en capacité de l’estimer.
S – Small : elle doit être de taille assez petite pour prioriser de façon sûre et éviter les effets tunnels. Essayez donc au maximum de découper finement vos User Stories.
T – Testable : la User Story doit raconter une histoire, dont les tests découlent de façon évidente.
Au delà de leurs structure et contenu, les User Stories sont avant tout un support de discussion entre le Product Manager et les autres membres de l’équipe permettant d’échanger sur le besoin et se mettre d’accord sur les solutions à développer.
Les enablers et Technical Stories
Les prérequis techniques au développement des User Stories sont formalisés en tant qu’enablers. Il peut s’agir d’une montée de version d’un composant technique, d’une refonte d’une brique technique.
Ces éléments contiennent la description des tâches techniques à réaliser ainsi que l’objectif recherché. Ils sont généralement rédigés directement par l’équipe de développement ou par un référent technique de l’équipe (lead engineer, architecte de solution).
Les bugs
Les bugs doivent apparaître dans le backlog afin que leur résolution soit priorisée vis-à-vis des nouvelles fonctionnalités. Ils sont généralement créés par la personne qui détecte l’anomalie. Il peut s’agir de vous en tant que Product Manager, notamment lorsqu’un bug est remonté directement par un utilisateur, mais également d’un membre de l’équipe, du service client ou de toute autre personne interagissant avec le produit.
Les tickets d’anomalie contiennent la description des étapes pour reproduire le bug, le résultat constaté et le résultat normalement attendu.
Les autres composants que vous pourrez rencontrer
En compléments des éléments qui se retrouvent dans (presque) tous les backlogs, chaque équipe est libre d’ajouter à sa guise d’autres éléments qui améliorent l’alignement et la visibilité des membres de l’équipe.
Les Spikes, sujets d’étude
Lorsqu’une demande n’est pas estimable parce qu’il y a trop d’inconnues, ou bien lorsqu’une phase de recherche est nécessaire avant de statuer sur la solution à implémenter pour une fonctionnalité donnée, il est possible de créer un ticket d’étude (ou Spike).
Les tickets d’étude, qui ne sont pas estimables comme des tâches classiques, sont généralement bornés dans le temps. Cela permet de réserver une partie de la capacité de l’équipe à la réalisation de l’étude tout en maîtrisant l’impact sur le reste des développements.
Afin de maximiser le succès de la phase d’étude, il est recommandé de définir en amont les livrables attendus. Si l’objectif n’a pas été atteint lorsque le temps imparti est écoulé, vous pouvez décider de prolonger la durée de l’étude ou bien de la reporter à plus tard.
Créer et faire vivre son backlog
Quel que soit le produit sur lequel vous travaillez, la création d’un backlog se fera à partir des solutions que vous aurez identifiées et priorisées avec votre équipe. Une fois votre première Epic créée, vous réaliserez toutes les étapes nécessaires pour préparer les développements.
Une fois que cette première Epic et les User Stories qui la composent seront passées en développement, vous viendrez étoffer votre backlog en y ajoutant de nouveaux éléments que vous aurez identifiés comme pertinents.
Un backlog est un organisme vivant, il n’est pas figé et doit au contraire évoluer. En tant que Product Manager, vous devez faire vivre le backlog. C’est à vous que revient la tâche d’ajuster l’ordre de priorité, de créer ou retirer des éléments.
Propres au cycle de vie du backlog, les activités d’affinage, ou refinement en anglais, sont centrales au processus de delivery.
Mener un backlog refinement
Le backlog refinement est un rituel collaboratif qui réunit autour de la table l’ensemble des participants au delivery. Seront présents a minima le Product Manager et les développeurs, et selon les organisations ou les besoins, le Product Designer, le testeur et tout autre partie prenante pertinente.
Le refinement des User Stories et notamment l’écriture des critères d’acceptation vont guider le développement et la validation de la User Story. Il est donc important que ces éléments soient partagés et compris par toute l’équipe.
Pendant les sessions de backlog refinement, vous pourrez réaliser les activités suivantes :
- Présenter les éléments prioritaires
- Rédiger les Epics et les User Stories
- Discuter des règles qui composent la solution
- Rédiger les critères d’acceptation
- Identifier la complexité d’une Epic ou User Story
Pour encadrer les sessions de refinement, vous pouvez vous appuyer sur des ateliers participatifs comme l’example mapping ou le 3 amigos.
Certaines équipes préfèreront ritualiser les refinements en définissant des créneaux hebdomadaires avec l’équipe, d’autres solliciteront les échanges en flux tendu selon les besoins et la bande passante de l’équipe.
🔎 Zoom sur l’atelier 3 amigos. L’atelier 3 amigos, réunissant autour de la table le Product Manager, un développeur et un testeur, aide à l’écriture des User Stories et notamment des critères d’acceptation. Avant l’atelier, le Product Manager écrit les exigences de la User Story. Celles-ci pourront être partagées au développeur et testeur en amont pour qu’ils préparent leurs questions. Lors de l’atelier, les exigences sont revues afin qu’elles soient comprises par tous, et les participants rédigent de façon conjointe la liste des tests d’acceptation. Si besoin, les règles à implémenter sont précisées.
Pour aller plus loin sur les tests d’acceptation.
A l’issue des backlog refinement, vous aurez levé toutes les incertitudes et vous pourrez vous lancer dans les développements sereinement.
Faire vivre votre backlog : nos conseils
Au risque de se répéter, le backlog est un outil vivant au service du produit il doit donc être mis à jour régulièrement. Voici quelques bonnes pratiques qui vous permettront d’en faire un outil efficace et performant.
- Sollicitez régulièrement votre équipe. Présentez quelques User Stories en fin de Daily, donnez de la visibilité sur les prochains refinements, n’attendez pas un refinement pour commencer à collecter régulièrement les avis sur la faisabilité technique, l’UX... (👉 en savoir plus sur le backlog preview)
- Un petit backlog pour un grand impact. Trop de sujets préparés à l’avance ne feront que remplir un backlog avec des éléments qui ne pourront pas être développés rapidement. Pourquoi écrire, discuter, estimer, bref prendre du temps de l’équipe, si elle n’a pas la capacité d’absorber la charge de développement ? Un petit backlog restera lisible pour l’équipe et vous pourrez ainsi vous concentrer sur la livraison des fonctionnalités à forte valeur ajoutée.
- Seules les User Stories prêtes sont éligibles au développement. N’ayez pas peur du syndrome du backlog vide, sélectionnez uniquement les User Stories prêtes pour votre sprint backlog permettra d’assurer la livraison et la qualité de vos développements. Et si vous manquez d’éléments fonctionnels prêts, rappelez-vous qu’il existe également les Technical Stories, Spike, Bugs et sujets d’amélioration continue !
- Supprimez des User Stories. Afin de garder un petit backlog, n’hésitez pas supprimer de temps en temps les éléments trop anciens. Cette opération est également recommandée lorsque vous reprenez un périmètre existant. Cela permettra de vous approprier le périmètre et valider la valeur de chaque solution.
- Un nouvel élément, une nouvelle priorisation. Lorsque vous découpez vos User Stories, faites une revue de la priorité par rapport aux autres éléments du backlog afin de toujours garder en haut de la pile les User Stories à valeur.
🔎 Backlog ou pas backlog ? La méthode Shape Up
Un backlog dans lequel sont notées toutes les nouvelles idées et qui est donc utilisé comme pense-bête peut vite devenir un fourre-tout illisible.
Dans Shape Up, Ryan Singer va juste qu’à recommander de ne pas s’embarrasser d’un backlog d’équipe et de se concentrer sur les solutions à construire sur le prochain cycle de 6 semaines. Les idées qui n’ont pas été retenues sont jetées. Il estime que si elles sont toujours pertinentes 6 semaines plus tard elles ressortiront naturellement. Chacun peut évidemment maintenir une liste de tâches à ne pas oublier, mais, dans la méthode Shape Up, il n’existe pas de backlog centralisé.
Il met notamment en avant le poids mental représenté par un backlog trop gros ainsi que le côté chronophage des ‘backlog refinements’ : “Les backlogs sont un gros poids que nous n'avons pas besoin de porter. Des dizaines, puis des centaines de tâches s'accumulent, dont nous savons tous que nous n'aurons jamais le temps de nous occuper. Cette pile croissante nous donne l'impression d'être toujours en retard, même si ce n'est pas le cas. Ce n'est pas parce que quelqu'un a pensé qu'une idée était importante il y a un trimestre qu'il faut s'y atteler encore et encore.
Les backlogs sont aussi une grande source de perte de temps. Le temps passé à examiner, soigner et organiser de vieilles idées empêche tout le monde d'avancer sur les projets opportuns qui comptent vraiment en ce moment.”
En résumé
Artefact essentiel des équipes agiles, le backlog tient une place centrale dans le cycle de vie d’un produit. Il sera ainsi utilisé pour :
- Organiser les éléments produit en fonction du risque et de la valeur
- Préparer les développements et générer des discussions avec l’équipe sur le fonctionnement attendu et les meilleures solutions pour y répondre
- Donner de la visibilité aux parties prenantes sur les nouveautés à venir
Maintenant que vous avez tous les éléments à disposition, c’est à vous de jouer !
