Product backlog : définition
Le product backlog est défini par le guide scrum comme étant “une liste ordonnée et émergente de ce qui est nécessaire pour améliorer le produit”. Xavier Koma ajoute que c’est une liste ordonnée de toutes les fonctionnalités/items, peu importe la forme ou le format de l’item, qui peut être de la user story, des spécifications, un brief, une maquette avec un powerpoint ou encore un gherkin, tant que l’équipe se met d’accord sur le format, de façon à conserver la même communication et la même compréhension.
Différences entre le cahier des charges et le product backlog
Qui est responsable du product backlog ?
Le Product Owner est le responsable du backlog et affine généralement ce dernier avec l’ensemble de l’équipe qui va faire maturer les users story pour qu’elles soient prêtes à être prises en charge par les développeurs. Il se peut que l’équipe de développement rédige les users stories techniques mais c’est toujours le Product Owner qui va prioriser l’ensemble des items.
Quelles sont les caractéristiques d’un product backlog ?
Le product backlog possède quelques caractéristiques remarquables. Claude Aubry a fournit l’acronyme “prouvé” pour les mettre en évidences :
Publique : toute l’organisation doit avoir accès à ce product backlog, c’est une question de visibilité.
Réduit : le product backlog doit être assez court, entre 40 et 60 items en général.
Ordonné : les items sont ordonnés par valeur décroissante, c’est à dire que l’item qui représente le plus de valeur se retrouve en premier. Le PO peut utiliser diverses techniques agile pour ordonner le backlog (voir ci-dessous).
Unique : un seul product backlog par produit !
Vivant : le Product Owner peut très bien ré-ordonner le product backlog à sa guise en fonction des besoins émergent du produit.
Émergent : le backlog n’est jamais complet, il est dynamique, il change constamment et il est toujours possible de rajouter de nouveaux items, de nouvelles fonctionnalités.
Comment construire un backlog ? Quelles sont les différentes étapes ?
Source : Eden tech labs
Le product backlog est un artefact important de scrum et il est l’outil de travail principal du Product Owner. Pour gérer efficacement un backlog, voici les 5 étapes les plus importantes :
- Prioriser le product backlog
- Vérifier la qualité des user stories
- Ajouter des critères d’acceptation
Identifier les besoins
Avant tout, il est nécessaire d’établir la vision du projet, c’est-à-dire de définir clairement l’objectif que le projet doit atteindre et de lister les différents acteurs. ll est important que cette vision soit acceptée et comprise de tous, elle doit faire consensus puisque l’équipe va devoir se rallier derrière le PO pour réaliser ce projet selon cet objectif.
Rédiger les user stories
Ensuite vient le moment de rédiger les users stories en gardant à l’esprit les questions : Quelles seront les fonctionnalités à créer ? Dans quel ordre devront-elles être livrées ? À qui sont-elles destinées ?
Pour en savoir plus sur comment rédiger une user story, consultez notre article !
On peut organiser son product backlog par :
- thème : regroupement logique d’un certain nombre de sujets définis par le Product Owner. Il n’y a pas de règle absolue tant que l’organisation est optimale. Ces fameux thèmes sont ensuite découpés par feature.
- feature : regroupement de user stories. Chaque feature va représenter un gros bloc fonctionnel, c’est-à-dire une grosse fonctionnalité sur le produit. Ces fonctionnalités vont être découpées en items, aussi appelés user stories.
- user story : les user stories – items – tâches ou encore éléments du backlog sont différentes appellations qui représentent des améliorations, des évolutions, des fixes, des fonctionnalités, des fonctions ou encore des bugs.
- sous-tâche : l’équipe de développement, en scrum par exemple, va découper l’ensemble des items en sous-tâches techniques lors du sprint planning, ou encore en sous-tâches anomalie.
Mais alors EPIC ça signifie quoi ?
Il y a plusieurs définitions. D’une part l’EPIC peut être au même niveau que la feature ou le thème mais à la base, la définition initiale de l’EPIC est une grande histoire, un besoin, avec peu de visibilité. Cette fameuse EPIC va être découpée en plusieurs user stories. On parle alors de maturation de l’EPIC pour devenir une user story. Dans un environnement SAFe l’EPIC est le premier niveau, avant le thème et donc le plus macro.
Il y a plusieurs sens possibles, le plus important c’est que l’équipe détermine sa propre définition et que tout le monde soit aligné.
Prioriser le product backlog
Lorsque le PO priorise le product backlog, il se heurte souvent à un problème commun : un processus de priorisation vague et incohérent. En tant que Product Owner, vous recevez quotidiennement des commentaires, de nouvelles idées et des demandes de fonctionnalités de la part de nombreuses parties prenantes et vous ne pouvez pas dire oui à tout le monde. Vos parties prenantes peuvent être confuses sur le fait que vous ayez choisi de prioriser un item plus qu’un autre et pourraient avoir le sentiment de ne pas avoir assez d’influence sur votre processus de priorisation. Une étape importante pour résoudre ces problèmes, consiste à standardiser le processus de hiérarchisation. Pour cela, il existe différentes techniques :
- Moscow
- Value vs EffoRT
- ICE
- RICE
- WSJF
Ces techniques créent une approche reproductible, plus transparente et moins aléatoire de votre priorisation.
Vérifier le niveau de qualité des user stories
Le Product Backlog Refinement, aussi connu sous le nom de Backlog grooming, est une pratique Scrum qui a le rôle comme son nom l’indique d’affiner le contenu du product backlog. C’est un moment idéal pour vérifier la qualité d’une user story avec toute l’équipe et de les remettre en question. Grâce aux inputs de chacun, le Product Owner pourra affiner les user stories sélectionnées pour le sprint. Avant de lancer une itération (cycle de 1 à 4 semaines), le Product Owner et l’équipe doivent s’assurer que les user stories soient réalisables par une personne et dans une itération.
Ajouter les critères d’acceptation
Afin d’optimiser les user stories, l’équipe doit définir ensemble, lors du Backlog Refinement Meeting, les critères d’acceptation d’une user story, qui permettront de vérifier si la user story peut être considérée comme “done”.
Pour rappel, la «Definition of Done (DoD)» c’est la qualité du produit livré. C’est la liste des critères permettant de décider qu’une fonctionnalité est «finie», et qu’elle peut être livrée à la fin d’un sprint. Elle est applicable à tous les items du backlog.
La vélocité d’une équipe est basée sur les fonctionnalités «finies». C’est un contrat entre l’équipe et le Product Owner (qui représente les parties prenantes et est la voix du client). Il définit clairement les critères à satisfaire pour qu’une user story, une itération, ou une version soit finie et puisse être livrée.
Une première version du backlog doit nécessairement être définie avant le premier sprint pour orchestrer les développements car le product backlog sert aussi d’outil de planification. En fonction de la vélocité de l’équipe (calculée en story point), les sprints sont créés et chargés avec des US estimées en story point. Au fur et mesure des sprints, le backlog s’étoffe avec de nouvelles Epic correspondant à un nouveau besoin identifié, de nouvelles US venant compléter une feature déjà développée, des bugs ou des tâches techniques pour prévenir la dette technique du produit.
Quels outils peut-on utiliser pour gérer un product backlog ?
Le product backlog peut être réalisé sur un simple fichier excel mais certains outils facilitent le suivi des user stories comme par exemple JIRA, Trello ou encore Projectboard.
Source : La Minute Agile, Scrum Life, Le Guide du Scrum Product Owner – Nutcache
