Si vous vous lancez dans la construction d'un Product Backlog pour la première fois dans un contexte Agile, vous pourriez ressentir un léger embarras quant à la manière de procéder sans commettre d'erreurs cruciales.
Ne vous inquiétez pas, c'est une tâche accessible, à condition de suivre quelques étapes clés. Cet article vous guidera à travers le processus pour vous assurer de produire un Product Backlog efficace.
Que vous soyez en gestion de projet traditionnel ou en utilisant les principes de l'agilité, vous aurez dans tous les cas une phase de cadrage afin de lister l’ensemble des éléments à réaliser.
Si vous êtes en gestion de projet traditionnel, cette liste de fonctionnalités sera fixe et vous utiliserez un diagramme de Gantt pour suivre les développements dans le temps.
Si vous utilisez une méthode agile, cette liste sera ordonnée, priorisée, composée de petits éléments et évoluera dans la temps. Dans la méthodologie agile Scrum, cette liste est un Artefact qu'on appelle le backlog produit.
Même si vous n'utilisez pas la méthode Scrum, si vous êtes en agile, il y a de fortes chances que vous ayez un Backlog Produit. C'est-à-dire, les éléments par ordre de piorité à réaliser pour proposer un produit de qualité à vos utilisateurs.
Ce Product Backlog est donc une liste d’éléments priorisés dans un tableau à une dimension. Cela signifie que les éléments les plus prioritaires sont en haut et les moins prioritaires sont en bas. On parle ici de priorité relative (et non pas absolue). Il n'y a pas de restrictions sur le type d'éléments composant un backlog. Vous pouvez retrouver dedans : des fonctionnalités, des actions d’amélioration, de corrections de bugs, de tâches techniques...
-i01fd.png)
Toujours dans la théorie de Scrum, ce Product Backlog est la responsabilité du rôle de Product Owner, et c'est donc à lui de le gérer dans le temps.
Le rôle du Product Owner est essentiel dans la gestion du Product Backlog car c'est lui qui assume les responsabilités suivantes :
Que le backlog produit existe
Qu'il est à jour
Qu'il est priorisé
Qu'il est compréhensible pour les autres membres de l'équipe produit (développeurs, Scrum Master…) ainsi que par les autres parties prenantes (sponsor, clients…)
Qu'il est partagé
Il a pour cela besoin d'impliquer les parties prenantes (personnes impliquées dans la réalisation du produit) et d'organiser les ateliers nécessaires pour le maintenir à jour.
Les différentes tâches définies dans le backlog servent alors de base de développement à l'équipe projet. Ces tâches seront développées les unes après les autres en respectant l'ordre de priorité donné afin de maximiser la valeur produite par l'équipe.
De plus, le fait de livrer régulièrement permettra de recueillir les retours utilisateurs et d'ajuster le Product Backlog en conséquence : le réordonner, supprimer ou ajouter des éléments…
Mais alors ? Comment créons-nous ce Backlog Produit, élément essentiel pour le développement de notre produit ?
Voici nos conseils.
Afin de construire un backlog cohérent avec vos ambitions projet, nous vous recommandons de procéder à minima en trois étapes :
Définition de la vision produit
Comprendre et se mettre en empathie avec vos utilisateurs
Découper, prioriser, affiner votre Product Backlog
Chaque étape est détaillée avec des conseils pratiques pour une mise en œuvre efficace.
Étape primordiale préconisé en agilité et en Product Management, la vision produit est une déclaration inspirante qui décrit l'objectif de votre produit ou d'une solution, en mettant en lumière les bénéfices qu'il ou elle apportera aux utilisateurs ou au marché.
Elle guide l'équipe de développement en fournissant une direction claire et en alignant les efforts vers un objectif commun. Cette vision doit être axée sur les besoins des clients ainsi que la valeur ajoutée que va proposer votre produit.
Cette vision produit est indispensable car c'est elle qui va par la suite vous permettre de déterminer l'ordre de vos éléments du Product Backlog, c'est-à-dire quels sont les éléments les plus importants et par lesquels il faut commencer pour répondre à notre vision.
Voici une liste de questions pour vous aider à constituer votre vision produit :
Pourquoi ce produit est-il développé ?
Pour qui faisons-nous ce produit ?
Quels sont leurs besoins ?
Quelles bénéfices nous voulons apporter à nos futurs utilisateurs ?
Comment pouvons-nous le mesurer ?
Une autre façon de définir votre vision produit est d'utiliser un format d'elevator pitch (il en existe plusieurs) comme celui-ci :
Pour {Utilisateurs cible}, qui ont {Besoins}, {Nom de votre produit} est un {catégorie de votre produit} qui {Proposition de valeur unique de votre produit}.
Contrairement à {Vos concurrents}, notre produit {Différenciateur}.
Vous n'avez plus qu'à compléter cette phrase en remplaçant les mots entre crochets.
D'autres outils sont connus et souvent utilisés pour définir une vision produit, comme notamment : Lean canvas, Product Vision Board, North Star Metric.
Quel que soit l'outil et la forme que vous utilisez, sachez que votre vision produit sera forcément fausse, et c'est normal.
Votre vision produit sera un regroupement d'hypothèses constitué des informations actuellement à votre disposition (cible utilisateurs, problématiques identifiées, ...). Celle-ci continuera à évoluer avec vos derniers apprentissages, et c'est ce qu'on souhaite.
Néanmoins, la vision produit reste obligatoire pour tout produit et un prérequis pour la constitution de votre product backlog.
Comme nous l'avons vu précédemment, un produit se veut de répondre aux besoins de vos utilisateurs. Afin de leur proposer une bonne expérience, vous avez donc besoin de vous mettre en empathie avec eux.
Ce travail est important car il vous garantie que vous rester proche de vos besoins utilisateurs lorsque vous allez imaginer les fonctionnalités à réaliser. Vous serez alors en mesure de lier vos réalisation à un besoin utilisateur et inversement.
Pour cela, nous vous conseillons d'utiliser un des outils suivant : User Story Mapping, Jobs to be done, impact mapping, customer journey map.
Nous ne détaillerons pas ici tous ces outils (vous trouverez facilement de la documentation sur internet) mais si vous hésitez, nous vous conseillons d'utiliser le User Story Mapping.
La majorité de ces outils vous proposerons de dessiner les parcours de vos utilisateur, c'est à dire les différentes étapes / activités par lesquelles passent vos utilisateur lorsqu'il utilisent votre produit. Vous aurez alors la possibilité de définir les fonctionnalités ou récits utilisateurs ("User Stories" en anglais) que vous devrez fournir pour répondre aux besoins de vos utilisateurs.
Les récits utilisateurs en agilité désignent les fonctionnalités à réaliser en prenant le point de vue des utilisateurs, de leurs besoins et de leurs attentes. Cette méthode vous garantit que chaque réalisation de ces récits est lié à un besoin utilisateur et évite donc des développements inutiles.
Un autre avantage de ces outils est qu'ils sont hautement collaboratif invitant chaque rôle du projet à partager les connaissances et amenant à une compréhension commune.
Ce travail fait, vous obtenez alors une liste d'éléments ordonnés à réaliser pour constituer votre produit et répondre à sa vision.
Vous savez donc pas quoi commencer, pourquoi et quel résultat vous en attendez.
Cette fois encore, ne cherchez pas la perfection. Il s'agit d'une première approche, qui sera là aussi optimisée au fil du processus de constitution du Product Backlog. D'ailleurs, n'oubliez pas, au gré des User Stories, à compléter la vision produit précédemment initiée.
L'étape précédente a permis de générer les différents éléments que vous allez devoir réaliser pour développer votre produit ainsi que la priorisation relative des éléments les uns par rapport aux autres : Vous avez la première version de votre backlog.
Cependant, ces éléments restent encore des coquilles vides qui vont demander de rentrer davantage dans le détail pour qu'ils puissent être réalisés avec un niveau le qualité suffisant.
Dans une approche agile, on va se contenter de détailler uniquement les éléments les plus prioritaires et on laissera les autres volontairement flou.
Comme notre product backlog va continuer à évoluer, on ne souhaite pas investir du temps à détailler des éléments de bas de tableau alors qu'ils ne seront peut être jamais réalisés.
Faire vivre votre product backlog va nécessiter une communication constante entre les utilisateurs (ou leurs représentants) et l'équipe projet.
Un product backlog qui évolue toutes les semaines est un bon indicateur d'une équipe agile. C'est ce qu'on appelle l'affinage du backlog, c'est-à-dire toutes les actions (découpage, précision, priorisation, etc.) nécessaires pour maintenir le backlog à jour.
Une fois ce travail effectué, votre Product Backlog est alors constitué et prêt à être utilisé. Par contre, ce product backlog vit et va devoir continuellement être re-prioriser et affiner en fonction des retours et apprentissages des utilisateurs.
Dans le cas où vous utilisez la méthode Scrum, vous allez utiliser des sprints (périodes de temps courtes et de durée fixe) pour planifier vos prochaines réalisation.
Pour cela, la construction de chaque sprint passe avant tout par la définition d'un objectif de sprint, à savoir la direction à prendre pour la prochaine itération.
L'objectif de sprint peut être vu comme un sous-ensemble de la vision produit.
Ainsi, pour définir votre objectif de sprint, posez-vous les questions suivantes :
Quelle est la priorité de cet objectif par rapport aux autres éléments du backlog ?
Quel est le problème ou le défi que nous cherchons à résoudre ?
Quel est le résultat souhaité à la fin du sprint ?
Quels sont les éléments du backlog (liste des tâches à accomplir) qui contribueront à cet objectif ?
On voit bien ici l'importance de la bonne définition initiale de la vision produit, sans laquelle les sprints seront difficiles à bâtir.
La collaboration est la clé du succès en matière d'agilité.
Impliquez toutes les parties prenantes, qu'il s'agisse des membres de l'équipe de développement, des responsables du produit, ou des utilisateurs finaux. Cette diversité d'opinions contribuera à enrichir le backlog.
Le Product Backlog n'est pas figé. Il doit être constamment révisé et ajusté en fonction de l'évolution des besoins du produit et des retours d'expérience.
Cette flexibilité est l'un des piliers de l'approche agile.
Votre product backlog doit être transparent et accessible pour toutes vos parties prenantes.
Pour cela, vous avez de nombreux outils sur les marchés à disposition : Jira, Trello, Azure devops, Teams ou même Excel.
Les quelques étapes que nous avons listé dans cet article peuvent être faites entre quelques heures et quelques semaines en fonction de la complexité du projet et de vos disponibilités.
Essayez de ne pas investir trop de temps et d'énergie sur cette partie là mais plutôt de fournir rapidement un premier résultat même imparfait.
En agilité nous considérons que commencer la réalisation est la meilleure façon de commencer à apprendre sur le produit.
En résumé, la création d'un Product Backlog n'est pas seulement une étape, mais un processus itératif.
Chaque itération rapproche le produit de sa vision initiale, et l'action rapide est souvent la meilleure façon d'apprendre et de s'adapter en temps réel.
Appliquez ces principes, et vous serez sur la voie du succès dans le développement Agile de vos produits.
Contact
julien.gardette@goveol.fr
Copyright 2022 Goveol