Formulaire de contact
Oops! Something went wrong while submitting the form.
Nous vous répondrons le plus rapidement possible.
Formulaire de contact
Nous vous répondrons le plus rapidement possible.
.png)
Dans une méthodologie de développement Agile, semi Agile ou même Dev Ops, le backlog produit constitue un réceptacle listant un ensemble de tâches ou fonctionnalités nécessaires pour atteindre les objectifs d’un produit défini par l’équipe.
Chaque produit développé possède généralement un seul backlog produit, lui-même attribué à une équipe. Il est le point central de tout projet Scrum et sous la responsabilité unique du Product Owner. C’est à partir de ce document que le PO planifie les sprints.
Le backlog est non seulement utile à l’équipe Produit, qui se réfère à son contenu pour prendre connaissance des solutions à développer, mais également aux autres équipes, tech, métiers, qui peuvent le consulter pour avoir de la visibilité sur les sujets en cours et à venir.
A sa genèse, il ne s'agissait que d'une simple pièce de bois ("log" en anglais). Les premiers marins jetaient un rondin par-dessus bord, à la poupe de leur bateau. En comptant le temps écoulé pour qu'il s'éloigne, ils estimaient ainsi la vitesse du navire.
Plus tard, les navigateurs affinèrent le système en reliant à une corde des pièces de bois à espaces réguliers. Les "logs" jetés à la mer permettaient de mesurer plus précisément l'allure du bateau. Les données collectées étaient soigneusement consignées sur un carnet de bord, un journal de logs.
Le terme "log" s'écarte ainsi de son sens originel car il désigne dès lors les carnets de bord des capitaines aux longs cours.
> journal de log = blog = ce qu’on a fait (Ce qui donnera Weblog = blog bien plus tard)
> backlog = journal à l’envers, on écrit ce qu’on prévoit de faire
Le Backlog moderne est donc le réceptacle qui contient l’ensemble du travail à réaliser pour qu’un produit soit complet.
Le backlog produit est composé de divers éléments, dont les plus communs sont les Epics, les User Stories, les enablers (ou tâches techniques / TS pour Technical Story) et les anomalies (ou bugs). C’est une liste ordonnée de tâches, de fonctionnalités ou d’éléments devant être terminés dans le cadre d’une feuille de route.
L’ensemble des éléments sont posés et nommés en fonction d’une granularité, de la plus générale à la plus précise. L'objectif étant d'être le plus clair et lisible possible en vue d’une meilleure organisation.
Voici un schéma des différentes composantes d’un Product Backlog
Une Epic (ou "épopée" en Français) est une brique fonctionnelle représentant un besoin utilisateur de haut niveau.
Les Epics sont des corpus de tâches qui peuvent être subdivisées en fonctionnalité ou en tâches spécifiques (appelées « user stories ») basées sur les besoins/demandes de clients ou d'utilisateurs finaux.
Par exemple, une Epic “gestion du panier client” pour un site d’e-commerce peut se décomposer en plusieurs fonctionnalités : “Ajouter un produit au panier”, “Modifier la quantité d’un produit au panier”, “Supprimer un produit du panier” etc… qui elles même seront subdivisées en US unitaires.
Les Epics sont un moyen utile d'organiser votre travail et de créer une hiérarchie. L'idée est de diviser le travail en plus petits livrables, de sorte à pouvoir réaliser de grands projets et à continuer de livrer de la valeur à vos clients sur une base régulière.
Dans un framework Agile, les user stories (“récit utilisateur” en français) constituent les unités de travail les plus petites. Elles représentent un objectif final (pas une fonctionnalité) exprimé du point de vue de l'utilisateur. C’est une explication non formelle dont le but est de définir comment un travail apportera une certaine valeur ajoutée au client.
Les user stories sont rédigées dans un langage simple. Elles n'entrent pas dans le détail. Des exigences sont ajoutées par la suite, une fois convenues par l'équipe.
Généralement, une User Story se compose :
Les prérequis techniques au développement des User Stories sont formalisés en tant qu’enablers. Il peut s’agir d’une montée de version d’un composant technique, d’une refonte ou création d’une brique technique nécessaires à la réalisation préalable d’une US.
Ces éléments contiennent la description des tâches techniques à réaliser ainsi que l’objectif recherché. Ils sont généralement rédigés directement par l’équipe de développement ou par un référent technique de l’équipe (lead engineer, architecte de solution).
Les bugs doivent apparaître dans le backlog afin que leur résolution soit priorisée vis-à-vis des nouvelles fonctionnalités mais aussi comptabilisés dans la charge de travail produite par la teamdev.
Ils sont généralement créés par la personne qui détecte l’anomalie. Il peut s’agir de vous en tant que Product Owner / Manager, notamment lorsqu’un bug est remonté directement par un utilisateur, mais également d’un membre de l’équipe, du service client ou de toute autre personne interagissant avec le produit.
Les tickets d’anomalie contiennent la description des étapes pour reproduire le bug, le résultat constaté et le résultat normalement attendu.
Ce Ticket est bien sûr à prendre en compte dans la planification de votre prochain sprint afin que l’erreur ne se reproduise plus et que la satisfaction utilisateur soit optimisée.
Avant toute planification de réalisation d’un projet, une fois les éléments saisis dans le backlog il y a forcément une étape d’estimation. Cette phase permet de mesurer le poids de chaque élément, c'est-à- dire la charge de travail nécessaire à sa réalisation, et donc celle du backlog. Vous entendrez également parler de complexité, souvent exprimée en story points.
L’évaluation de la réalisation d’une tâche peut être basée sur des notions différentes comme des jours/homme, des heures, des story points points ou même les tailles des t-shirts (XS, S, M, L, XL…).
De bout en bout et en écrivant toutes les stories nous obtenons le Product Backlog qui sera tiré sur le poids des story (donné par valeur).
Comme toujours:
Artefact essentiel des équipes agiles, le backlog tient une place centrale dans le cycle de vie d’un produit. Composé de plusieurs éléments ayant tous leur place, Il sera utilisé pour :
La communication entre les membres de l’équipe est une partie cruciale de la hiérarchisation du backlog produit. Pour réussir à faire le tri et à terminer les tâches dans un délai raisonnable, vous devez collaborer avec votre équipe et suivre la méthode Scrum.
Maintenant que vous savez tout sur le backlog, rdv sur notre article “construire son backlog” pour aller encore plus en profondeur dans la méthode de création.
Si vous souhaitez créer ou optimiser votre Product BackLog, n'hésitez pas, réservez un call.
Abonne toi à notre newsletter pour recevoir l’essentiel de l’actualité Design toutes les deux semaines dans ta boîte mail !
.png)
