Qu’entend-on par backlog ou product backlog ?
Vous faites partie d’une équipe agile utilisant la méthode Scrum, et vous souhaitez connaître toutes ses particularités ? Ou bien vous êtes Product Owner et cherchez à savoir comment créer et gérer votre product backlog avec efficacité ? Ou encore, vous êtes simplement curieux de découvrir les intérêts de cette méthodologie, et la valeur que le passage à l’agilité peut apporter à vos projets ?
Cet article vous révèle en quoi le backlog de produit est un allié pour votre gestion de projet agile, et vous en livre tous ses secrets.
Dans le framework de projet Scrum, on distingue deux types de backlogs :
Cet article détaille en particulier l’utilisation du backlog de produit. Géré et ordonné par le Product Owner, le backlog de produit recense et hiérarchise toutes les demandes liées au produit en fonction de leur niveau de priorité.
Instrument pratique de communication interne autour du projet, il contient notamment des informations clés, telles que :
Exemple de product backlog — © The Scrum Primer
Le backlog de produit intervient dans le cadre d’une méthode agile, qui est une approche itérative et incrémentale de développement.
Plus spécifiquement, il est utilisé au sein de la méthode Scrum.
La·le Product Owner a l’entière responsabilité du product backlog. Elle·il :
La·le PO n’attribue pas directement des tâches à effectuer à l’équipe de développement, mais les communique via le product backlog : en haut de la liste figurent les éléments les plus importants, c’est-à-dire ceux qui doivent être livrés en priorité.
Au cours de la réunion de planification du sprint (sprint planning), l’équipe de développement détermine quelles user stories seront développées au cours du prochain sprint et répartit les tâches.
Elle s’organise ensuite en fonction de ses capacités et produit un sprint backlog pour le prochain sprint à réaliser. À cette occasion, elle affine l’ordre de priorité défini dans le product backlog et traduit chaque user story en spécifications techniques.
Le product backlog peut s’apparenter à un outil de recueil des besoins et une liste détaillée des fonctions attendues d’un produit. Il est voué à évoluer au fur et à mesure, sur toute la durée de vie du produit.
Le sprint backlog, lui, peut s’apparenter à un outil de recueil des spécifications techniques à réaliser pour produire les demandes relatives au product backlog.
Un cahier des charges, au contraire, est un document de spécification précis et fixe, élaboré en amont du projet, qui énumère toutes les fonctionnalités dont le produit devra être pourvu.
La roadmap produit, quant à elle, est une représentation sur le moyen à long terme du processus de création du produit et de son avancement. En accord avec la stratégie globale de l’entreprise, elle donne le cap et la vision produit, et définit les grandes orientations communes à prendre. Elle peut être révisée selon des facteurs de changement internes ou externes à l’entreprise.
On peut se représenter un backlog comme une file d’attente des demandes client. En tant que Product Owner, il convient de les trier, de les accepter ou non, et de les prioriser. Voyons comment en 4 étapes.
En vous appuyant sur la roadmap produit et sur les exigences recueillies auprès des parties prenantes, vous dressez la liste exhaustive de toutes les fonctionnalités attendues sur le produit.
Certains besoins exprimés resteront à l’état d’idée, car vous devez valider l’acceptabilité de chacun avant de leur donner suite, ou non.
Il peut s’agir :
Une fois les fonctionnalités retenues, vous pouvez les formaliser et les rédiger sous la forme d’US, qui seront découpées, affinées et ordonnées par la suite.
Pour déterminer quelles fonctionnalités développer, vous avez la possibilité d’utiliser un outil de planification stratégique et de management visuel tel que l’impact map.
Exemple d’impact map — © Project Freak
Pour créer votre impact map :
Le backlog produit peut rapidement se remplir en accueillant une grande diversité d’idées, d’où l’importance cruciale de les hiérarchiser en fonction de leur importance. Les niveaux de priorité définis correspondent à l’ordre dans lequel elles seront développées.
Vous pouvez à ce stade les classer et les ordonner selon leur valeur, en cohérence avec la stratégie de l’entreprise, mais pas uniquement.
👉 Pour prioriser les éléments du backlog, appuyez-vous sur plusieurs critères, dont :
Si en théorie, la·le Product Owner est seul responsable de la hiérarchisation des éléments, il peut faire appel, dans l’absolu, à d’autres parties prenantes pour le réajuster :
Tout cela dans le but de concilier les bénéfices attendus et les efforts à fournir.
Avant chaque réunion de planification du sprint, passez en revue le backlog pour vérifier de nouveau si la priorisation est appropriée et tient compte de nouveaux facteurs intervenus au cours du sprint précédent :
☝️ Veillez à construire la première version de votre backlog avant le premier sprint. Il est votre outil de base pour planifier et coordonner tous les développements à venir.
Déterminez alors un planning de livraison des fonctionnalités attendues pour ce sprint. Une fois que le sprint et le planning d’itération sont fixés avec l’équipe technique, prenez soin de n’accepter aucune nouvelle US jusqu’à la nouvelle itération. C’est sur la base de ce périmètre étanche que l’équipe de développement va construire son sprint backlog qu’elle tentera de réaliser entièrement pendant le sprint concerné.
Le backlog d’un produit se destine à une longue vie, probablement équivalente à celle du produit : il évoluera en continu, sera complété, réévalué, nettoyé, etc.
Pour faire vivre votre backlog, afin de développer un produit à fort impact et grande valeur ajoutée, votre maintenance du backlog de produit sera déterminante.
Voici quelques derniers conseils :
Et vous, comment vous organisez-vous pour gérer votre backlog ? N’hésitez pas à nous partager vos bonnes pratiques en commentaire !
