Le backlog, la liste évolutive qui orchestre vos développements produit

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 :

• le backlog de produit (ou product backlog), qui est une liste de fonctionnalités attendues sur le produit (une fonctionnalité s’appelle généralement « user story »),
• le sprint backlog est une de liste de tâches en cours ou à réaliser par l’équipe de développement sur une période (itération).

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 :

• le nom de l’élément,
• la description de la fonctionnalité,
• la charge de travail,
• le sprint en cours,
• le statut,
• la priorité, etc.

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 :

1. recueille les besoins exprimés par les autres services de l’entreprise, souvent le marketing, ou directement exprimés par les clients ;
2. évalue leur acceptabilité ;
3. les rédige sous forme d’user stories (US) et reste seul maître de leur priorisation au sein du backlog.

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 :

• du développement de nouvelles fonctionnalités,
• de l’amélioration de fonctionnalités existantes,
• de la résolution de bugs ou de problèmes techniques.

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 :

1. définissez vos objectifs métiers,
2. caractérisez l’audience que vous ciblez (personae),
3. identifiez les besoins de chacun de vos types de cibles,
4. distinguez les fonctionnalités qui répondront précisément à ces besoins pour finalement remplir vos objectifs à travers elles.

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 :

• le degré d’importance de la fonctionnalité pour le client/l’utilisateur (valeur business),
• l’estimation de la quantité de travail nécessaire,
• les difficultés à prévoir pour sa mise en œuvre,
• la connaissance technique ou métier gagnée par l’équipe en la réalisant.

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 :

• les clients pour leurs commentaires et feedback,
• le scrum master pour la priorisation des objectifs et l’ordre logique des tâches sur un plan technique,
• l’équipe de développement pour l’optimisation des charges de travail.

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 :

• le feedback du client,
• la révision des estimations initiales,
• l’apparition de nouvelles contraintes, etc.

☝️ 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 :

• Limitez le nombre d’éléments du backlog. Pour gérer sereinement l’arrivée de nouvelles idées, intégrez les plus pertinentes et n’hésitez pas à mettre de côté sur une liste distincte les demandes à plus faible priorité. Cela évite de surcharger le backlog de produit, qui ne contient que les US classées comme prioritaires. Vous avez aussi la liberté de clôturer certains tickets s’ils excèdent les capacités de l’équipe de développement.
   
• Prévoyez un créneau régulier pour ranger votre backlog. Recentrez-le sur les véritables urgences et vérifiez que vous disposez de tous les éléments pour entamer le prochain sprint. Vous pouvez notamment instaurer la cérémonie de backlog grooming pour faire le point avec l’équipe de développement une fois par sprint.
   
• Utilisez un logiciel spécialisé dans la gestion de projet agile comme monday.com pour vous faire gagner du temps, et optimiser le suivi de votre product backlog. Des solutions adaptées aux méthodes agiles et Scrum existent, conçues spécialement pour les équipes de projet agiles. Leurs fonctionnalités :
  • améliorent la communication entre les parties prenantes,
  • favorisent la collaboration et la visibilité sur les tâches du projet,
  • offrent un suivi de projet efficace grâce à des notifications et des indicateurs pour tenir vos objectifs.

Et vous, comment vous organisez-vous pour gérer votre backlog ? N’hésitez pas à nous partager vos bonnes pratiques en commentaire !