Product Backlog : tout savoir pour bien le construire

Incontournable des méthodes agiles, le Product Backlog traduit la Roadmap en tâches concrètes à réaliser par l’équipe de production. Et comme toute bonne traduction, le Product Backlog ne doit ni dénaturer le produit digital à créer, ni susciter de débats au sein de l’équipe sur ce qui est lui est réellement demandé. Comment éviter les contresens et concilier l’esprit du projet et sa réalisation ? Voyons cela ensemble !

Concrètement, le Product Backlog est une liste de tâches priorisées définissant les caractéristiques d’un produit. Le Product Owner le construit en collaboration avec l’équipe de production et le client, à partir des besoins exprimés dans la Roadmap.

Le Backlog permet également de planifier plus précisément les itérations et les livraisons associées. En effet, il donne de la visibilité sur la quantité d’éléments à développer et sur leur ordre d’exécution. Enfin, il précise l’estimation de temps et l’effort nécessaires pour terminer chacune des tâches identifiées.

La première version du Product Backlog permet d’évaluer la charge de travail des équipes de production. Cela permet de planifier les livraisons des futurs Sprints. Cette version n’aura de cesse d’évoluer tout au long du projet, au rythme des retours de tests et de l’identification de nouveaux besoins.

Dans un premier temps, le Product Owner décrit le produit digital dans le Product Backlog. Cette description se décompose en EPICS (une fonctionnalité ou un bloc de fonctionnalités), chacune découpée en plusieurs User Stories. Ces tâches à accomplir pour développer la fonctionnalité, peuvent elles-mêmes être redécoupées en sous-tâches si besoin. Ensuite, le Product Owner estime avec l’équipe de production l’effort à fournir pour réaliser chaque user story. À Kanbios, cet effort est exprimé en story points. Nous utilisons la simulation de Monte-Carlo pour consolider l’estimation et raffiner la planification du projet.

Vient ensuite l’étape de priorisation. Chez Kanbios, nous utilisons notamment la méthode MoSCoW pour la priorisation du Backlog. Les fonctionnalités « vitales », sans lesquelles le produit ne peut pas fonctionner, et les fonctionnalités qui ont le plus de valeur ajoutée pour l’utilisateur final sont placées en haut du Product Backlog et développées en priorité. Celles qui sont « accessoires » ou pour lesquelles trop de questions subsistent sont repoussées en bas de la liste.

Il existe deux grandes catégories de modifications apportées au Product Backlog au cours d’un projet.

En premier lieu, il est possible d’ajouter des User stories, d’en supprimer ou bien de compléter les existantes avec de nouvelles sous-tâches. Ces actions sont souvent consécutives aux retours de tests utilisateurs. En effet, ceux-ci ont pu relever des bugs, des améliorations à porter au produit ou bien faire émerger de nouveaux besoins. Chaque incrément peut également donner lieu à l’ajout de tâches spécifiques qui préviennent ou réduisent la dette technique du produit digital final.

L’estimation en story points d’une user story peut également changer au cours du projet. On peut la revoir à la hausse (ex : une fonctionnalité qui se révèle plus complexe à développer qu’au premier abord). Ou bien la revoir à la baisse, grâce à la montée en compétences et en efficacité de l’équipe de production.

Ces évolutions ont un impact sur la planification des sprints, ainsi que sur la consommation des ressources allouées au projet (temps, moyens, personnes). C’est pourquoi chaque modification doit faire l’objet d’un consensus entre toutes les parties prenantes. Par ailleurs, seul le PO a le droit de modifier le Product Backlog en tant que garant du projet. Ni les clients, ni l’équipe de production ne peuvent ajouter, modifier ou supprimer des éléments du Product Backlog.

On connait le Product Backlog Refinement aussi sous le nom de Backlog grooming. Il correspond à l’affinement des user stories du Product Backlog avant leur intégration dans un Sprint. Avant de lancer une itération (ou Sprint), le Product Owner et l’équipe doivent s’assurer que les user stories sont réalisables et livrables dans le temps imparti.

Cet affinement se traduit souvent par des échanges avec les différentes parties prenantes du projet et un redécoupage de la user story envisagée. Aucune user story n’est intégrée dans un Sprint Backlog s’il manque des informations. De même si le besoin exprimé par cette dernière semble flou.

Avec la popularisation des méthodes agiles, de nombreuses entreprises se sont mises à proposer des applications qui permettent de créer et gérer facilement des Product Backlogs : JIRA, Asana, Notion… et même Excel, pour les afficionados des tableaux croisés dynamiques !

Nos Product Owners utilisent Trello et JIRA en fonction des projets et des préférences de nos clients. En effet, toutes les parties prenantes ont accès au Product Backlog pour suivre l’évolution du projet et échanger sur la priorisation des actions. Il est donc important que ce support soit clair, facile à lire et facile à manipuler par tous. Le Backlog n’a pas uniquement valeur de documentation du déroulement du projet et de l’évolution du produit digital développé. Il est également un support pour faciliter la communication entre toutes les parties prenantes, au cours de la production.

• Le Product Backlog est une liste de tâches priorisée. Il définit toutes les fonctionnalités à développer pour créer un produit digital.
• Le Product Owner construit le backlog en collaboration avec toutes les parties prenantes du projet.
• Un Product Backlog a valeur de documentation du produit digital développé. Il est également un outil d’aide à la planification des livraisons. Enfin, il est un support de communication entre les parties prenantes au cours du développement du produit.