---

Qu’est-ce que le Scrum Product Backlog ? La réponse pourrait vous surprendre !

Le Product Backlog (Scrum Backlog), ou Scrum Product Backlog, est l’élément central de gestion de toutes les exigences connues d’un produit Scrum.

Il réunit le travail émergent et ordonné nécessaire pour améliorer le produit et atteindre ses objectifs. Les exigences comprennent les besoins fonctionnels et non fonctionnels ainsi que les fonctionnalités liées à l’expérience utilisateur et à la conception de l’interface.

Le Product Backlog contient les demandes de fonctionnalités et leurs user stories de haut niveau. Il peut aussi inclure des exigences préalables ou complémentaires, comme la création d’environnements de test et de développement. Les user stories nécessaires pour corriger des anomalies connues, réduire la dette technique ou améliorer certaines fonctions logicielles y ont également leur place.

Chaque produit possède un Product Backlog unique, partagé par toutes les Scrum Teams qui y travaillent. Le Scrum Product Owner est responsable de sa création, de sa maintenance et de son affinage. Le Product Backlog ne répond pas, et ne devrait pas répondre, à la question de savoir comment ces exigences seront développées et livrées.

C’est le rôle de la Scrum Team. Elle détermine et documente dans les Sprint Backlogs les tâches nécessaires pour satisfaire ces exigences. Le Product Backlog et le Sprint Backlog sont des entités physiquement distinctes, même si les éléments du premier déterminent le contenu du second.

Le responsable du Scrum Product Backlog est le Scrum Product Owner. Le Scrum Master, la Scrum Team et les autres parties prenantes y contribuent afin de constituer une liste plus complète de user stories pour assurer la réussite du produit.

Utiliser un Scrum Product Backlog n’empêche pas la Scrum Team de créer d’autres artefacts pour gérer son travail : synthèse des rôles utilisateurs, descriptions des flux, consignes d’interface, storyboards ou prototypes d’interface, par exemple. Ces artefacts ne remplacent toutefois pas le Scrum Product Backlog ; ils complètent et précisent son contenu.

Le Product Backlog est un document évolutif. Tout comme le logiciel s’améliore progressivement, le Product Backlog s’enrichit au fil du temps. Scrum n’exige pas en soi de processus distinct de gestion des changements. Le Scrum Product Owner crée les premières versions du Product Backlog à partir de sa meilleure compréhension initiale du produit.

En observant l’évolution du produit de Sprint en Sprint et en approfondissant sa connaissance des exigences des clients, le Scrum Product Owner ajoute, supprime et affine les exigences du Product Backlog.

Le Scrum Product Owner priorise les exigences du Product Backlog. Plus un élément du Product Backlog est prioritaire, plus il doit être détaillé. La Scrum Team peut ainsi comprendre facilement ces exigences et créer les tâches nécessaires pour les réaliser.

Les Developers dimensionnent aussi les éléments du Product Backlog selon les besoins ; les points de story constituent une technique facultative. Les estimations des user stories prioritaires doivent être affinées pour les préparer à la planification du Sprint.

Chaque Scrum Product Backlog possède des attributs qui le distinguent d’une simple liste de tâches :

• Une user story apporte toujours une valeur métier ou technique au client, au responsable métier et aux utilisateurs finaux,
• Toutes les user stories sont priorisées et classées par priorité décroissante,
• Le niveau de détail d’une user story dépend de sa position dans le Scrum Product Backlog,
• Les user stories sont dimensionnées selon les besoins, avec une technique adaptée,
• Le Scrum Product Backlog est un document évolutif,
• Le Product Backlog décrit le travail sur le produit ; le plan d’exécution détaillé des Developers appartient au Sprint Backlog.

Les user stories apportent de la valeur aux clients, à l’entreprise et aux systèmes

Chaque user story du Scrum Product Backlog doit apporter de la valeur au client. Les user stories sans valeur pour le client constituent un gaspillage de ressources et doivent être éliminées. Le Scrum Product Backlog peut inclure des user stories pour :

• Spécifier les exigences fonctionnelles et non fonctionnelles,
• Résumer la décomposition globale du travail nécessaire au lancement du produit logiciel,
• Mettre en place des environnements de développement et de démonstration hors production,
• Corriger les défauts.

Exemple de Scrum Product Backlog

Certaines tâches n’apportent pas de valeur directe aux fonctionnalités du système ou aux clients. Elles doivent néanmoins créer de la valeur en améliorant la qualité, en réduisant la dette technique et en facilitant la maintenance du produit à long terme.

Le Product Backlog est un document évolutif

Le Scrum Product Backlog évolue tout au long du projet. De nouvelles user stories peuvent être ajoutées, et les stories existantes modifiées, détaillées ou même supprimées. Les exigences d’un projet Scrum ne sont plus figées dès le départ comme avec la méthode en cascade.

L’ensemble final des exigences est au contraire élaboré par itérations, parallèlement aux incréments logiciels qui émergent.

Cette approche diffère de l’ingénierie traditionnelle des exigences. Elle permet toutefois à la Scrum Team de maximiser la valeur client et de limiter le gaspillage de ressources.

Différents niveaux de détail

Les exigences du Scrum Product Backlog peuvent présenter différents niveaux de granularité. Seules les exigences à réaliser dans les prochains Sprints doivent être définies plus en détail. Les autres user stories doivent rester générales et être traitées « juste à temps », avant que la Scrum Team ait besoin d’en savoir davantage.

Il est inutile d’investir du temps et des ressources pour préciser trop tôt ces exigences, car certaines peuvent changer ou disparaître avant leur réalisation. Le traitement « juste à temps » des exigences est l’un des grands atouts de Scrum pour faire face aux « inconnues inconnues » de vos projets.

Pas de tâches détaillées dans le Product Backlog

Le Product Backlog décrit normalement le travail sur le produit plutôt que la décomposition détaillée des tâches. Le Scrum Product Owner définit les exigences avec les clients et les parties prenantes métier avant de les présenter aux réunions d’affinage du Backlog ou de planification du Sprint. Les Developers sont responsables de la décomposition détaillée des tâches et de l’organisation de leur travail.

Le Scrum Product Backlog est classé par priorité

Toutes les user stories sont priorisées, puis le Scrum Product Backlog est classé par priorité décroissante. Le Scrum Product Owner réalise cette priorisation avec le soutien de la Scrum Team. La valeur ajoutée pour le client, les coûts, les risques et les dépendances sont les facteurs les plus couramment examinés. Le Scrum Product Owner peut ainsi décider de ce que l’équipe doit ensuite construire et livrer.

Dimensionner les éléments du Product Backlog

Les Developers peuvent dimensionner les éléments avec une technique convenue, par exemple des points de story sur une échelle de type Fibonacci ou des tailles relatives S/M/L/XL/XXL. Scrum n’impose ni échelle unique ni estimation de chaque élément lointain. Nous y reviendrons plus loin. Ces estimations influencent ensuite la planification de la capacité des Sprints, le contenu du Sprint Backlog et les plans de livraison.

Travailler avec le Backlog

Le Scrum Product Backlog exige un soin et une attention réguliers. Il doit être géré avec rigueur, car il constitue la référence pour comprendre votre produit logiciel.

Au début du projet, il contient de nombreuses stories générales dont la pertinence pour la réussite du projet peut varier. À mesure que le projet avance de Sprint en Sprint, le Scrum Product Owner et l’équipe approfondissent leurs connaissances.

Le contenu du Scrum Product Backlog reflète donc de plus en plus le produit et les enseignements de l’équipe.

Après sa mise en place initiale, le Scrum Product Backlog doit être entretenu en permanence. Cela consiste à :

• Décrire et ajouter les nouvelles exigences découvertes, puis modifier ou supprimer les exigences existantes selon les besoins,
• Ordonner (prioriser) le Scrum Product Backlog en plaçant les user stories les plus importantes en tête,
• Préparer les user stories prioritaires aux prochaines planifications de Sprint (généralement pendant les réunions d’affinage du Backlog),
• (Ré)estimer les user stories du Scrum Product Backlog (généralement pendant les réunions d’affinage du Backlog).

Le Scrum Product Owner veille à ce que le Scrum Product Backlog reste en bon état. Son entretien est toutefois un processus collaboratif. Une part raisonnable de la capacité des membres doit être réservée à l’affinage continu du Product Backlog, en plus du temps consacré aux événements Scrum.

Cet entretien collaboratif permet aussi de clarifier les exigences et de renforcer l’adhésion des membres de la Scrum Team au produit qui se construit.