Qu’est-ce qu’un backlog ? Comment le construire et le gérer ?

Qu’est-ce qu’un backlog ?

Le backlog est une liste de tâches priorisées définissant les caractéristiques d’un produit. Il est un des éléments fondamentaux de la méthodologie Scrum. Il s’agit de l’outil de travail principal du Product Owner qui se charge de recueillir les besoins auprès des parties prenantes et de les transformer en liste de fonctionnalités prêtes à être développées par l’équipe de développement.

Communément, on peut formaliser ce items sous forme de Users Stories (US). A ces US peuvent également s’ajouter des évolutions et des anomalies recensées sur le produit.

Le backlog pourrait être assimilé aux traditionnelles spécifications fonctionnelles et techniques dans la méthode du cycle en V. A la différence du cahier des charges élaboré en tout début de projet, le backlog est lui construit tout au long de la vie du produit.

Au lancement de chaque incrément, à l’issue d’un ou plusieurs sprints de développement, le Product Owner enrichit le backlog avec :

• les feedbacks remontés par les utilisateurs finaux
• l'émergence de nouveaux besoins

A terme, l’intégralité de ce qui constitue le produit aura été référencé dans le backlog.

Différences entre le cahier des charges et le backlog

Construire son product backlog

Une fois les contours du produit définis et les features prioritaires identifiées, l’équipe commence à les décomposer le plus finement possible pour pouvoir développer.

Dans le framework d’agilité à l’échelle SaFe on parle par exemple de :

• Features (fonctionnalités)
• Epic (User Story non affinée)
• puis de User Stories qui seront insérées dans le product backlog au fur et à mesure.

Ensuite les différentes US sont priorisées en fonction leur valeur, ce qui déterminera leur ordre pour le développement :

• cette US est indispensable pour le fonctionnement de mon produit et est peu coûteuse à développer donc je la place en haut du backlog
• celle-ci est une fonctionnalité secondaire et nécessite des développements lourds, je la dépriorise en bas du backlog.

Evolution du product backlog
Source : https://wikiagile.cesi.fr/

Une première version du backlog doit nécessairement être construit avant le premier sprint pour orchestrer les développements car il sert aussi d’outil de planification. En fonction de la vélocité de l’équipe (calculée en story point), les sprints sont créés et chargés avec des US estimées en story point.

Au fur et mesure des sprints, le backlog s'étoffe avec de nouvelles Epic correspondant à un nouveau besoin identifié, de nouvelles US venant compléter une feature déjà développée, des bugs ou des tâches techniques pour prévenir la dette technique du produit.

Gérer son backlog : du grooming à la réalisation

Le backlog est public pour toutes les parties prenantes afin de suivre l’avancement mais est principalement maintenu par le Product Owner. Il est l’outil unique de l’équipe dans lequel l’ensemble des spécifications du produit sont rassemblées.

Il n’est pas monolithique car avant d’arriver dans le sprint en cours, l’US va suivre tout un parcours en passant par différents stades.

Workflow de la User Story dans le backlog

Dans son livre sur “Scrum” Claude Aubry définit les “bacs” suivants :

• Le bac d’idées (ou bac à sable)

C’est là qu’on y stocke les idées sous la forme la plus brute possible, qui deviendront peut être des US. Une idée peut être déposée par tout le monde : Product Owners, développeurs, parties-prenantes... Le Product Owner y fait régulièrement le ménage car toutes les idées ne seront pas développées.

• Le bac d’affinage

C’est là que les Stories sélectionnées par le Product Owner atterrissent pour la rédaction. Elles y entrent grosses (souvent sous forme d’Epic) pour finir petites et découpées le plus finement possible. Ce processus s’appelle le backlog grooming ou backlog refinement. Cela se traduit par un ensemble de conversations avec les parties-prenantes pour affiner le besoin et l’équipe pour définir les spécifications. Les US sont à terme découpées et estimées (grâce au Planning Poker par exemple) par l’équipe.

• Le bac de départ

Il s’agit des US qui sont prêtes à être embarquées dans un sprint. Elles sont entièrement rédigées et sont définies comme “prêtes” en fonction de la Definition of Ready de l’équipe. La Definition of Ready est en quelque sorte le contrat qui définit qu’une US contient tous les éléments pour être développée sereinement dans un sprint. Cela permet de fiabiliser l’engagement.

Le processus de grooming du backlog

Focus sur le sprint backlog

En complément du product backlog, on parle aussi de sprint backlog. Celui-ci contient uniquement les US qui seront développées durant le sprint et qui sont arrivées dans le bac de départ. En général, les éléments du sprint backlog suivent un workflow plus approfondi en fonction de l’organisation que l’équipe Agile a choisi avec des étapes de relecture de code, de tests, de mise en recette, en preprod etc…

Ce workflow est souvent représenté sous forme de Kanban pour suivre au mieux l’avancée des développements et mesurer l’atteinte des objectifs de sprint. Les US finalisées atterrissent dans le bac de fin quand elles respectent la Definition of Done de l’équipe et font généralement l'objet de la démo. En fonction des retours des différentes parties prenantes, le Product Owner ajoutera de nouvelles Stories dans le bac d’affinage.

Le sprint backlog sous Jira
Source : Altassian.com

Les outils pour gérer son backlog

Bien que la gestion d’un product backlog puisse se faire avec un fichier Excel ou via du management visuel, nous vous conseillons d’utiliser un outil spécifique pour le suivi de vos User Stories. En voici quelques uns :

• JIRA: la référence et le plus poussé disposant de plein d’add-on (payant)
• Trello : le plus ludique (gratuit)

Mais aussi :

• Asana
• Notion
• Gitlab
• Redmine
• Projectboard

Tu peux choisir ta voie 🔥

Découvre notre catalogue de formations pour devenir un expert du Product !