Nous sommes tous d’accord pour dire que pour atteindre les objectifs d’un projet, les besoins et le travail à réaliser doivent être listés quelque part.
Avec les méthodes de gestion de projet traditionnelles telles que le cycle en V ou waterfall, le cahier des charges a ce rôle.
En Scrum, c’est le product backlog qui assure ce rôle.
Dans cet article, nous allons balayer ensemble les indispensables à savoir sur le backlog de produit, les différences entre un product backlog et un cahier des charges, et les bonnes pratiques pour gérer efficacement son backlog.
Définition d’un product backlog
Le product backlog est une liste ordonnée et émergente d’éléments que l’on prévoit de faire afin de répondre à un product goal. Il s’agit d’un artefact Scrum et de l’outil principal du product owner. Il est la seule source de travail de l’équipe Scrum.
Contrairement au cahier des charges, le backlog produit ne contient pas une liste exhaustive des choses à réaliser. Il est émergent, c’est à dire qu’il vit, qu’il évolue et qu’il se construit dans le temps, tout au long des sprints.
Il faut plutôt voir le product backlog comme une liste d’options qu’on se réserve le droit de faire dans le futur, sans aucune obligation.
Les items du backlog sont ordonnés et hiérarchisés selon un ordre logique, afin d’apporter le plus rapidement possible le maximum de valeur au client, tout en minimisant la durée du projet.
Qu’est-ce que le product goal ?
Le product goal est l’engagement de l’équipe Scrum dans le projet. C’est également l’engagement lié à l’artefact du backlog produit. Il est défini en amont et est fixe tout au long du projet : il représente l’état du produit à atteindre à la fin du projet.
Tout ce qui est dans le product backlog peut changer et évoluer. C’est en fonction de ce qui est intéressant de faire maintenant que l’on ordonne le product backlog et que l’on prépare les sprints suivants. Tout ça dans un unique but : atteindre le product goal.
Le product backlog incite à des échanges et des choix qui font qu’un programme est robuste. Tout ne peut pas être prioritaire.
Constantin Guay
Product backlog vs Cahier des charges
Le product backlog est une liste du travail à effectuer pour délivrer un produit en mode agile. Il est dynamique, évolutif et émergent. Le cahier des charges est une liste exhaustive des besoins en gestion de projet classique. Il est fixe. On parle alors de périmètre figé.
Vu sur QRP International
Pour aller + loin : J’explore dans cet article les différences entre un product backlog et une roadmap produit.
Product backlog vs Sprint backlog
Le product backlog est unique, et existe durant tout le cycle de vie du produit. Le sprint backlog est un backlog dédié au sprint en cours, et n’existe que durant le sprint. Les éléments du product backlog sont tirés afin d’être inscrits dans le backlog du sprint en cours, pour développement.
Plus on se rapproche du moment où un élément va être pris en compte dans le sprint backlog par l’équipe de développement, plus cet élément est détaillé et précis et se rapproche de la definition of ready.
Voici le lien schématisé entre product backlog et le sprint backlog
Pour aller + loin : Je liste dans cet article toutes les différences qui existent entre le product backlog et le sprint backlog.
Caractéristiques d’un product backlog
Un product backlog se caractérise par plusieurs éléments.
Bien qu’on parle généralement de l’acronyme DEEP, Claude Aubry, auteur de plusieurs livres sur Scrum et l’agilité, propose l’acronyme PROUVE.
Un product backlog est DEEP
L’acronyme décrit quatre caractéristiques primordiales d’un product backlog :
- D pour Détaillé de manière appropriée.
Il contient des éléments avec la bonne granularité : suffisamment petits et détaillés pour être compréhensibles par l’équipe de développement et les parties prenantes. Mais pas trop pour éviter de faire du travail pour rien. - E pour Estimé.
Chaque élément est estimé de manière relative les uns par rapport aux autres, quant aux points d’efforts nécessaires pour les réaliser. Cette estimation est réalisée en planning poker. - E pour Évolutif.
Le product backlog n’est pas figé. Il évolue régulièrement, et émerge au fur et à mesure des itérations. Il reflète les besoins pour réaliser un produit à un instant t. - P pour Priorisé.
Les éléments sont priorisés, du plus important (celui qui apporte le plus de valeur) au moins important (sera potentiellement réalisé plus tard). La priorisation est nécessaire afin de livrer le plus de valeur au client le plus tôt possible.
Un product backlog est PROUVE
L’acronyme PROUVE, proposé par l’auteur Claude Aubry, décrit bien quelles sont les caractéristiques d’un backlog produit.
Analysons cela ensemble.
- P pour Public.
Il doit être accessible par l’équipe Scrum et l’ensemble des parties prenantes, à des fins de transparence. - R pour Réduit.
Un backlog produit n’est pas une liste de courses exhaustive. Il représente le travail qu’on souhaiterait réaliser à un instant t, et doit être réduit. Entre 40 à 60 items, c’est parfait. - O pour Ordonné.
L’élément qui a le plus de valeur doit être positionné en haut de la liste. Le product owner doit savoir ordonner et hiérarchiser les éléments entre eux selon la valeur apportée. - U pour Unique.
Le product backlog est unique au produit : il n’y en a qu’un, même s’il y a plusieurs équipes travaillant sur le produit. - V pour Vivant.
Il est dynamique. On peut ajouter, supprimer ou modifier des éléments, redécouper les user stories, réordonner les items, etc… Un backlog produit vit et évolue au quotidien. - E pour Émergent.
Les besoins émergent au fur et à mesure des sprints et de ce que l’équipe apprend en cours de route.
2 livres de référence sur Scrum
Je vous recommande ces deux livres de Claude Aubry afin d’approfondir votre connaissance de Scrum et d’adopter les bonnes pratiques pour continuer à développer l’agilité dans votre équipe et dans votre organisation.
Pour aller + loin : Consultez également cet article pour découvrir les meilleurs livres sur le product management.
Avantages et intérêts du product backlog
Le backlog produit est un élément indispensable en Scrum et en agile, qui permet d’atteindre l’objectif de produit.
Voici les avantages à son utilisation :
- Liste le travail que l’on aimerait réaliser.
Il reflète le travail à réaliser pour délivrer un produit à un instant t. ça évite la charge mentale de l’équipe Scrum et les trous de mémoire aux mauvais moments. - Permet d’ordonnancer et de hiérarchiser les éléments entre eux.
Plutôt que d’avoir une todolist en mode « à l’arrache », le product backlog est ordonnancé. Les éléments ayant le plus de valeur sont classés en haut de la liste. - Permet d’orchestrer les releases produit et les sprints.
La priorisation des éléments du backlog permet de les regrouper entre eux afin d’atteindre des objectifs de sprint lors des prochains sprints, et de livrer de nouveaux incréments produit. - Encourage un environnement de travail flexible et productif.
Les tâches en sont pas gravées dans le marbre, et le product owner n’est pas celui qui décide ce que doit faire l’équipe de développement dans les prochaines semaines. - Favorise la transparence.
Le product backlog est public, et est consultable à tout moment par l’équipe Scrum ainsi que par les parties prenantes du projet. - Encourage la collaboration et la co-construction.
Comme il est en constante évolution, cela force le product owner, l’équipe de développement et les parties prenantes à travailler ensemble.
Qui est responsable de la gestion du backlog produit ?
Le product owner est responsable de la création, du maintien et de la priorisation du product backlog. Il assure ce travail en collaboration avec l’équipe de développement et les parties prenantes pour faire émerger un backlog produit qui a du sens et apporte de la valeur au client.
Les parties prenantes et l’équipe de développement peuvent influencer le product owner sur les éléments à ajouter / modifier / supprimer dans le backlog produit, mais c’est toujours le product owner qui aura le dernier mot.
Par ailleurs, lorsqu’un product backlog est modifié, il est indispensable d’avoir un consensus chez les parties prenantes. En effet, cela peut impacter la planification des prochains sprints, la consommation des ressources allouées au projet, le budget ou encore la date estimée de fin de projet.
Quand le product backlog est-il créé ?
Le backlog produit est généralement créé avant le premier sprint et au plus tard lors du sprint planning de ce premier sprint. Cependant, le product goal doit déjà être connu de l’équipe Scrum, puisqu’il est la raison d’être du projet.
N’attendez pas d’avoir un product backlog complet avec plus de 500 éléments pour commencer à travailler.
Pour être agile, il est indispensable de se confronter le plus vite possible aux utilisateurs afin de valider vos hypothèses, plutôt que de devoir jeter des semaines de travail à la poubelle.
Préférez faire ce qui est vraiment bon pour le produit et pour l’utilisateur, plutôt que de persister à faire ce qui est prévu.
Peut-on avoir plusieurs product backlog ?
Le product backlog est unique au produit, peu importe le nombre d’équipes qui travaillent à sa réalisation. Le guide Scrum est très clair à ce sujet. Il ne doit donc y avoir qu’un seul et unique backlog produit.
Charge ensuite au product owner et à l’équipe de développement (ou aux équipes) de s’organiser afin de recenser tous les éléments dans le backlog.
Doit-on avoir un Product backlog complet pour commencer les sprints ?
Il n’est pas nécessaire d’avoir un product backlog complet afin que l’équipe de développement commence à travailler sur les premiers éléments et les premiers sprints. On peut commencer un sprint avec un product goal et déterminer les premiers éléments à développer.
Le backlog produit est évolutif et émergent, contrairement au cahier des charges des méthodes de gestion de projet traditionnelles. Seul l’objectif produit (le product goal) est fixe.
Le product backlog s’affine dans le temps et se construit petit à petit en équipe.
Est-ce qu’on peut travailler sur quelque chose qui n’est pas dans le product backlog ?
Il est tout à fait possible d’identifier un travail à réaliser qui n’apparaît pas dans le backlog produit. C’est précisément dans ce cas que l’on considère que le product backlog est émergent. Cet élément doit intégrer le backlog, car on vient d’identifier de nouvelles choses à faire.
Pour faire simple, si c’est utile et que ce n’est pas dans le backlog produit, on le rajoute.
C’est normal : le product backlog est vivant, dynamique, évolutif et émergent.
Comment gérer le product backlog ?
Afin de construire et gérer efficacement un product backlog, il est nécessaire de respecter quelques étapes :
- Établir l’objectif du produit.
L’objectif à atteindre avec le produit à réaliser est déterminé en amont du projet. - Identifier les besoins des parties prenantes.
Le product owner travaille en partenariat avec les parties prenantes pour identifier ce dont ils ont réellement besoin. - Hiérarchiser les éléments du backlog entre eux.
Les éléments du product backlog sont ordonnancés et priorisés selon ce qui a le plus de valeur maintenant. - Détailler les éléments prioritaires.
Les items ayant le plus de valeur sont affinés et détaillés, puis pris par l’équipe de développement dans le sprint en cours. - Vérifier la qualité des items et ajouter des critères d’acceptation.
Le product owner s’assure que l’équipe a toutes les informations nécessaires afin de tester son travail et de s’assurer que ça répond bien à ce qui est attendu. - Actualiser le product backlog régulièrement.
Un backlog est vivant et dynamique, il est normal qu’il évolue constamment.
Pour aller + loin : Il y a tellement à dire sur le sujet que j’ai détaillé dans cet article toutes les étapes et sous-étapes nécessaires pour construire et gérer efficacement un backlog produit.
Faut-il monter l’équipe avant de commencer à construire le product backlog ?
Il n’y a pas de réponse toute simple à cette question. D’ailleurs, Constantin Guay, de la chaîne Youtube Scrum Life, l’explique très bien :
Avoir l’équipe dès le début du projet peut ouvrir des opportunités. Le product owner a un feedback immédiat, et cela permet de maximiser la valeur apportée lors du premier sprint.
D’un autre côté, si le produit n’est pas faisable, on a constitué l’équipe et payé des gens pour rien.
Certes, pendant ce temps-là, l’équipe de développement ne code pas et ne réalise pas le produit. Mais elle fait émerger le backlog du produit en partenariat avec le product owner, elle priorise, détaille et estime les premiers éléments, et prépare ainsi le premier sprint.
Comment découper le product backlog ?
Le backlog de produit peut contenir de multiples éléments de tailles diverses, certains plus détaillés que d’autres. Bref, ça peut vite devenir complexe de s’y retrouver.
D’ailleurs, plus un travail est gros, plus c’est compliqué d’estimer ce qu’il y a vraiment à réaliser et de faire des estimations. Plus un élément est volumineux, plus la marge d’erreur est importante, plus on s’approche de la méthode d’estimation du pifomètre.
Il est donc nécessaire de découper le backlog produit.
Je vous recommande d’utiliser trois niveaux dans votre backlog :
- Les thèmes.
Il s’agit d’un simple label permettant de regrouper les fonctionnalités entre elles. Par exemple, un thème pourrait être « panier » sur un site de e-commerce. - Les features, ou epics.
Il s’agit de ce qui est demandé par les parties prenantes. C’est le début de maturation des récits utilisateurs. - Les user stories, ou récits utilisateurs.
Ces éléments plus petits sont détaillés et formulés afin d’être indépendants, le plus possible. Ce sont ces user stories (US) qui sont ensuite développées par l’équipe de développement.
Quel niveau de détails avoir dans le product backlog ?
Le backlog de produit peut contenir des éléments plus ou moins détaillés en fonction de leur ordonnancement et de la priorisation effectuée par le product owner. Les items prioritaires sont les plus détaillés et respectent souvent la definition of ready, quand les items lointains sont plus flous.
Les items doivent être suffisamment détaillés pour éviter le flou ou les mauvaises interprétations. Mais ils ne doivent pas être trop détaillés, au risque d’avoir fait du travail pour rien.
Le product owner définit des items, le plus souvent des user stories, sans détailler à outrance. L’objectif reste de pouvoir le plus rapidement possible commencer à travailler et fournir de la valeur au client.
Il doit donc trouver l’équilibre entre précision et détail, afin de présenter le product backlog à l’équipe de développement et aux parties prenantes.
Comment prioriser le product backlog ?
Les éléments du product backlog sont priorisés par le product owner en fonction de la valeur qu’ils apportent au client. Les éléments apportant le plus de valeur sont placés en haut du backlog et sont généralement les plus détaillés, et ceux qui vont être développés le plus vite.
Cette priorisation s’effectue selon le degré d’urgence et d’importance de chaque élément, et selon sa valeur.
Bien sûr, le product owner ne le décide pas seul. Il échange régulièrement avec l’équipe de développement ainsi qu’avec les parties prenantes du projet, qu’il représente. Le product backlog est ainsi co-construit.
Les éléments les plus prioritaires du product backlog sont ensuite pris par l’équipe de développement et déplacés dans le sprint backlog. Ces éléments seront donc développés lors du sprint actuel.
Pour aller + loin : La méthode MoSCoW peut vous aider à mieux prioriser votre backlog de produit : je vous en parle en détails dans cet article.
Qu’est-ce que le Product backlog refinement ou backlog grooming ?
Le product backlog refinement, ou backlog grooming, est une activité récurrente réalisée par le Product Owner, qui consiste à affiner et détailler les éléments que contient le backlog de produit.
Ce travail constant d’affinage permet d’avoir des items suffisamment détaillés pour les prendre en développement dans le prochain sprint, via le backlog de sprint.
Le product backlog refinement s’effectue toujours en partenariat avec l’équipe de développement, afin de faire émerger et co-construire le backlog, mais également afin que le product owner puisse avoir le feedback de l’équipe sur les différents éléments.
Comment gérer les évolutions du product backlog ?
On l’a vu, le backlog de produit est vivant, dynamique, évolutif. Il émerge au fur et à mesure des sprints et de l’apprentissage de l’équipe.
Mais du coup, comment gérer les évolutions du product backlog au quotidien ?
Je vous explique tout cela en détails dans cet article.
Pour les plus pressés, voici les points-clés :
- Ajouter des éléments chaque fois que nécessaire.
Il peut s’agir de thèmes, features, epics, user stories, spikes, gherkin, bugs, etc… - Ordonnancer les éléments selon la valeur apportée.
Les éléments les plus prioritaires se trouvent en haut de la liste et sont généralement les prochains à être pris en compte. - Réaliser des ateliers de backlog refinement.
Cela permet d’affiner les éléments et de les découper en éléments plus petits et plus précis. - Faire des estimations via le planning poker.
On estime ainsi les points d’efforts pour la réalisation de chaque élément du backlog. Utile pour planifier ensuite les sprints et ajouter des éléments au backlog de sprint. - S’assurer que les parties prenantes sont d’accord.
Modifier le backlog de produit a un impact sur la planification des sprints ainsi que la consommation des ressources allouées au projet. - Seul le product owner peut modifier le product backlog.
Ni les clients, ni l’équipe de production ne peuvent ajouter, modifier ou supprimer des éléments du Product Backlog.
Pour aller + loin : Découvrez dans cet article les 17 erreurs à ne pas commettre lorsque vous gérez votre product backlog.
Quels outils pour gérer un product backlog ?
Le product backlog est généralement géré en management visuel, et est représenté sur un board. Si l’équipe est à distance, les outils les plus utilisés sont Trello, Jira, Projectboard ou encore un simple fichier Excel.
Peu importe l’outil que vous souhaitez utiliser, vous devez respecter trois points :
- Le product backlog est transparent pour l’équipe Scrum.
Ce n’est pas quelque chose que le product woner gère dans son coin. L’équipe Scrum doit pouvoir le consulter, et discuter des différents éléments entre eux. - Il doit être inspectable par les parties prenantes.
Le backlog de produit doit être visible par tous, équipe comme parties prenantes du projet. Vous devez donc faire en sorte, peu importe l’outil choisi, qu’il soit consultable facilement à tout moment. - Il doit pouvoir vivre et évoluer.
L’outil choisi doit donc permettre facilement l’ajout ou le retrait de nouveaux éléments dans le product backlog.
Comment mesurer l’état d’avancement du backlog de produit ?
L’état d’avancement du backlog de produit est mesuré principalement via deux outils :
- La burnup chart.
Elle permet d’analyser l’avancement du travail réalisé sur une période donnée par rapport à la globalité du travail prévu. - La burndown chart.
Elle permet de visualiser le travail fini sur un sprint, en respectant la definition of done, et permet d’estimer l’avance ou le retard dont dispose l’équipe.
1 ) Burnup chart
La burnup chart est un graphique construit de la manière suivante :
- En abcisse (axe horizontal), on représente les unités de temps. Il peut s’agir de dates précises, de semaines, du nombre de sprints réalisés, etc…
- En ordonnée (axe vertical), on représente les points d’efforts nécessaires pour réaliser le travail.
On trace alors deux courbes :
- La première représente l’effort total que l’équipe de développement doit fournir afin de traiter tous les éléments du product backlog et de réaliser le produit.
- La seconde représente l’effort de travail réalisé par l’équipe. Autrement dit, le travail terminé.
Avec le temps la seconde courbe se rapproche de plus en plus de la première, qui est l’objectif à atteindre par l’équipe. On mesure ainsi l’avancement du travail réalisé, et ce qu’il reste à faire dans le backlog de produit.
Voici un exemple pour mieux comprendre la notion :
Exemple de burnup chart
2 ) Burndown chart
La burndown chart de release est un graphique construit de la manière suivante :
- En abcisse (axe horizontal), on représente les unités de temps. Il peut s’agir de dates précises, de semaines, du nombre de sprints réalisés, etc…
- En ordonnée (axe vertical), on représente les points d’efforts nécessaires pour réaliser le travail.
On trace alors deux courbes :
- La première représente l’effort total nécessaire pour réaliser le produit, lissé dans le temps. Cela permet d’estimer la date de fin de projet.
- La seconde représente l’effort de travail réel fourni par l’équipe, au fur et à mesure des sprints.
L’intérêt de ce graphique est de comparer ces courbes entre elles. L’équipe peut ainsi être en avance ou en retard sur ce qui a été estimé. Cette donnée permet de mesurer l’état d’avancement du projet, et de faire des projections sur le nombre de sprints restants.
Voici un exemple pour mieux comprendre la notion :
Exemple de burndown chart