S’il est correctement hiérarchisé, le backlog agile facilite la planification des livraisons et des itérations, et en plus il communique toutes les tâches priorisées par l’équipe. Cela permet de clarifier les attentes avec les parties prenantes et les autres équipes, en particulier lorsque celles-ci vous fournissent du travail supplémentaire. Il est possible également de définir le temps de développement comme un indicateur clé.

Savoir comment créer un “product backlog” n’est pas forcément évident car il peut être facile de s’y “perdre”. Au fur et à mesure que le temps passe et que le produit évolue, ce qui était autrefois une simple liste d’articles prioritaires devient complexe, voire difficile à ordonner. Travailler à partir d’une importante liste de fonctionnalités peut alors rendre la navigation dans le Backlog produit compliquée. 

Aussi, à mesure que des éléments de priorité plus élevée sont réalisés, de nouvelles tâches sont ajoutées et les éléments les plus anciens s’accumulent tout en bas de la liste. Si vous vous reconnaissez dans ce qui a été énoncé ci-dessus, lisez cet article pour comprendre comment créer un Product Backlog.

Nous parlons d’ordonner avec le backlog, en faisant allusion à l’ordonnancement en logistique pour la gestion des stocks…

Construire son product backlog

Un backlog produit est une liste hiérarchisée de tâches destinées à l’équipe de développement. Il est créé à partir de la feuille de route et de ses exigences. Les éléments les plus importants figurent en tête du backlog produit. Ainsi, l’équipe sait ce qu’elle va livrer en priorité. L’équipe de développement ne suit pas le backlog au rythme du Product Owner et celui-ci n’impose pas de tâches à l’équipe de développement. Cette dernière récupère les tâches à réaliser dans le backlog produit en fonction de ses capacités, soit en continu (Kanban), soit par itération (Scrum).

Une fois les contours du produit définis et les futures 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 ou des méta User Story, un assemblage cohérent de User Story non encore affiné)

– puis de User Stories qui seront insérées dans le product backlog au fur et à mesure.

Ensuite les différentes User Story sont priorisées en fonction de leur valeur, ce qui déterminera leur ordre pour le développement. 

La garantie d’un backlog robuste

Une fois le backlog créé, il est important de l’actualiser régulièrement afin de l’adapter au programme. Les responsables produit vont passer en revue le backlog avant chaque réunion de planification. L’objectif c’est de s’assurer que la priorisation est correcte et que le feedback de la dernière itération a bien été intégré. La revue régulière du backlog est souvent appelée « préparation » dans les cercles Agile (certains parlent d’amélioration).

 Au fur et à mesure que le backlog s’allonge, il sera résumé par les responsables produit en tâches à court terme et à long terme. Les tâches à court terme vont être complètement définies avant d’être libellées comme telles.
Cela signifie que :

• des user stories complètes ont été rédigées, 
• la collaboration avec les équipes de conception et de développement a été organisée, 
• et que l’équipe de développement a procédé à des estimations. 

Les tâches à plus long terme peuvent rester un peu vagues, même s’il est judicieux d’obtenir de l’équipe de développement une estimation approximative pour pouvoir les hiérarchiser. Le mot clé ici est « approximative » : ces estimations évoluent une fois que l’équipe aura parfaitement compris en quoi consiste ces tâches à plus long terme.