Un backlog agile est la liste ordonnée de tout ce qui pourrait améliorer le produit. Le product owner en est responsable : création des éléments, souvent rédigés sous forme de user stories, et classement selon la valeur, le risque et l'urgence. À chaque sprint, l'équipe y prend le travail qu'elle peut terminer.
Ce vocabulaire revient à l'examen PMP comme dans les équipes produit. Il vient de deux textes de référence : le Scrum Guide pour une équipe, et le Scaled Agile Framework (SAFe) quand plusieurs équipes travaillent sur le même produit. Les sections qui suivent reprennent ces textes, montrent comment rédiger et prioriser les éléments, puis listent les confusions que les questions d'examen cherchent à repérer.
Qu'est-ce qu'un backlog agile, selon le Scrum Guide ?
Le Scrum Guide (version de novembre 2020) définit le Product Backlog comme une liste « émergente et ordonnée » de ce qui est nécessaire pour améliorer le produit, et comme la source unique du travail entrepris par l'équipe Scrum. Deux mots portent toute la définition. Émergente : la liste n'est jamais terminée, elle change avec ce que l'équipe apprend des utilisateurs, du marché et de ses propres livraisons. Ordonnée : chaque élément a un rang, et ce rang dit ce qui sera traité d'abord. Une liste de souhaits non classée n'est pas un backlog.
Le même Scrum Guide rend le product owner redevable de la gestion du backlog, en quatre volets :
- formuler et communiquer explicitement l'objectif de produit (Product Goal), c'est-à-dire l'état futur du produit vers lequel l'équipe planifie ;
- créer et communiquer clairement les éléments du backlog ;
- ordonner ces éléments ;
- veiller à ce que le backlog soit transparent, visible et compris.
Le product owner peut déléguer ce travail à d'autres personnes, mais reste redevable du résultat. Le guide précise aussi que toute personne qui veut modifier le backlog doit convaincre le product owner, et que l'organisation entière doit respecter ses décisions. Cette règle évite le backlog à plusieurs propriétaires, où chaque service ajoute ses priorités et où plus personne ne tranche.
Le dimensionnement n'appartient pas au product owner : selon le Scrum Guide, ce sont les développeurs qui feront le travail qui en sont responsables. Le raffinement (refinement) consiste à découper les éléments et à leur ajouter des détails : description, ordre, taille. Un élément que l'équipe peut terminer en un sprint est considéré comme prêt à être sélectionné lors de la planification du sprint. C'est un effort continu, pas une réunion annuelle de mise à plat.
Point souvent mal compris : le Scrum Guide ne parle jamais de user stories. Il parle d'éléments du Product Backlog (Product Backlog items), sans en imposer la forme. La user story est une pratique complémentaire, très répandue, que l'équipe adopte ou non. Côté gestion de projet, le backlog est l'outil de gestion du périmètre des approches adaptatives : il remplace la liste d'exigences figée et validée en début de projet. L'article sur la distinction entre backlog et lignes de base détaille ce passage du prédictif à l'adaptatif.
Product backlog, sprint backlog, release backlog : trois horizons de planification
Le product backlog couvre tout le produit, mais personne ne planifie tout au même niveau de détail. Les équipes découpent donc le travail selon l'horizon : le produit entier, la prochaine livraison, le prochain sprint. Les cadres de référence ne nomment pas ces niveaux de la même façon, ce qui explique une bonne partie des confusions.
| Backlog | Horizon | Qui en décide | Contenu | D'où vient le terme |
|---|---|---|---|---|
| Product backlog | Toute la vie du produit | Product owner | Tout ce qui peut améliorer le produit : fonctionnalités, epics, user stories, corrections, travail technique | Scrum Guide |
| Sprint backlog (ou iteration backlog) | Un sprint, d'une durée fixe d'un mois ou moins | Les développeurs | Objectif du sprint, éléments sélectionnés, plan pour livrer l'incrément | Scrum Guide |
| Release backlog | Une livraison qui couvre plusieurs itérations | Product owner, avec les parties prenantes | Éléments visés pour une version donnée | Pratique de planification des releases, absente du Scrum Guide |
| Team backlog | Une équipe au sein d'un train de livraison | Product owner | User stories et enablers, dont des stories issues des features de l'ART backlog | SAFe |
Le sprint backlog est, selon le Scrum Guide, composé de l'objectif du sprint (le pourquoi), des éléments du product backlog sélectionnés pour le sprint (le quoi) et d'un plan d'action pour livrer l'incrément (le comment). Le guide le décrit comme un plan « par et pour les développeurs » : le product owner influence ce qui entre dans le sprint, mais ne répartit pas les tâches. Le terme « iteration backlog » désigne la même chose hors du vocabulaire Scrum. L'article consacré au sprint backlog et à son rôle dans les approches adaptatives approfondit ce niveau.
Le release backlog sert quand il faut annoncer à un client ou à une direction ce qui sortira dans la prochaine version. Il regroupe les éléments du product backlog visés pour cette livraison, sur plusieurs itérations. Ce n'est pas un artefact du Scrum Guide : retenez-le comme un outil de planification, qui reste révisable comme le reste du backlog.
Dans les grandes organisations, SAFe décrit le team backlog comme un système Kanban qui sert à recueillir et gérer les user stories et les enablers destinés à améliorer la solution. Le product owner le gère, souvent face à des parties prenantes qui ne s'accordent pas sur les priorités. SAFe le présente comme une liste de travail souhaité plutôt que comme une liste d'engagements. Une partie des stories provient des features de l'ART backlog, le backlog du train de livraison qui coordonne plusieurs équipes : c'est ce niveau que visent les recherches sur le « program backlog ». La formation SAFe Product Owner et Product Manager traite cette articulation entre les deux niveaux.
Comment rédiger une user story que l'équipe peut livrer
Le Scaled Agile Framework définit les stories comme de courtes descriptions d'une petite fonctionnalité souhaitée, écrites du point de vue de l'utilisateur, assez petites pour qu'une équipe les termine en quelques jours ou moins. SAFe distingue les user stories, qui décrivent une valeur pour l'utilisateur final, et les enabler stories, qui couvrent l'exploration, l'architecture, l'infrastructure et la conformité. Les critères d'acceptation et les tests rendent la story précise et protègent la qualité.
Le format le plus courant tient en une phrase : « En tant que [rôle], je veux [action] afin de [bénéfice] ». Par exemple : « En tant que candidat au PMP, je veux voir le total des heures de formation déjà validées, afin de savoir si mon dossier de candidature est complet. » Cette phrase n'est pas une spécification ; c'est le point de départ d'une conversation entre le product owner, les développeurs et les utilisateurs. Les critères d'acceptation fixent ensuite ce qui sera vérifié :
- le total s'affiche sur la page de profil, en heures ;
- seules les formations dont l'attestation est déposée entrent dans le total ;
- un message indique l'écart restant quand le seuil exigé n'est pas atteint.
Avant de faire entrer une story dans un sprint, vérifiez quelques critères simples :
- Un rôle réel : « l'utilisateur » ne suffit pas ; précisez qui, pour savoir à qui demander un avis.
- Un bénéfice explicite : sans le « afin de », impossible de juger la valeur, donc de prioriser.
- Des critères d'acceptation vérifiables : chacun doit pouvoir être testé par oui ou par non.
- Une taille qui tient dans un sprint : sinon, découpez par parcours utilisateur, par règle métier ou par type de données, jamais par couche technique.
- Une indépendance raisonnable : une story qui ne peut être livrée qu'avec trois autres se priorise mal.
Beaucoup d'équipes résument ces critères par la grille INVEST : indépendante, négociable, porteuse de valeur, estimable, petite, testable. La hiérarchie usuelle du backlog va de l'epic (un grand besoin, sur plusieurs sprints) à la feature, puis à la story, elle-même décomposée en tâches dans le sprint backlog.
Ne confondez pas critères d'acceptation et définition de terminé. Les premiers sont propres à une story. La définition de terminé (Definition of Done) s'applique à tout l'incrément : le Scrum Guide indique qu'au moment où un élément satisfait la définition de terminé, un incrément naît. Une story qui remplit ses critères mais n'est ni testée ni intégrée selon la définition de terminé n'est pas terminée.
Prioriser le backlog : valeur, risque, dépendances et coût du retard
Le Scrum Guide exige que le backlog soit ordonné, sans imposer de méthode. En pratique, le product owner arbitre entre plusieurs critères :
- la valeur pour l'utilisateur et pour l'organisation ;
- le risque : traiter tôt ce qui peut faire échouer le produit, pour l'apprendre quand il est encore peu coûteux de changer ;
- l'urgence : une échéance réglementaire ou une fenêtre de marché ;
- les dépendances : un élément peut en débloquer plusieurs autres ;
- l'apprentissage : un petit élément qui valide une hypothèse peut valoir plus qu'une grosse fonctionnalité.
SAFe propose une méthode chiffrée, le Weighted Shortest Job First (WSJF), présenté comme un modèle de priorisation qui séquence le travail pour un bénéfice économique maximal. Le WSJF se calcule comme le coût du retard relatif divisé par la durée relative du travail. Le coût du retard additionne trois composantes estimées de façon relative : la valeur pour l'utilisateur et l'entreprise, la criticité temporelle, et la réduction du risque ou l'ouverture d'opportunités. Le mécanisme est simple : à coût du retard comparable, le travail le plus court passe d'abord, car il livre de la valeur plus tôt. Un gros élément très attendu peut ainsi passer après un petit élément moyennement attendu. SAFe rappelle aussi que le WSJF ignore les coûts déjà engagés : ce qui a été dépensé ne justifie pas de continuer.
D'autres techniques existent, comme le classement MoSCoW (must, should, could, won't), utile pour négocier le contenu d'une livraison à date fixe. Quelle que soit la méthode, le résultat reste un ordre unique : deux éléments ne partagent pas la première place. L'article sur le backlog priorisé et la définition itérative du périmètre montre comment cet ordre construit le périmètre au fil des itérations, et celui sur la mise à jour du backlog par le product owner décrit le rythme de révision.
Les projets d'intelligence artificielle posent un cas particulier : on ne sait pas toujours, avant d'essayer, si un modèle atteindra la qualité attendue. Le backlog y gagne à contenir des éléments formulés comme des hypothèses à vérifier (« nous pensons que tel jeu de données permet telle prédiction ; nous le saurons quand… »), classés haut quand ils réduisent l'incertitude. C'est la composante « réduction du risque » du WSJF appliquée à l'expérimentation. L'article sur l'intelligence artificielle dans le contexte projet élargit ce point.
Ce que l'examen PMP vérifie sur le backlog
PMI publie dans son plan de contenu de l'examen PMP (Examination Content Outline) les domaines évalués et la place des approches prédictives, agiles et hybrides. Consultez la version en vigueur sur le site de PMI avant de réviser : les questions sur le backlog relèvent des approches agiles et hybrides, et elles portent rarement sur une définition récitée. Elles décrivent une situation et vous demandent qui agit, avec quel outil, à quel moment.
Les pièges reviennent d'une question à l'autre :
- Croire le backlog figé une fois validé. Il est émergent et réordonné en continu.
- Confondre product backlog et release backlog. Le premier contient tout ; le second est un sous-ensemble visé pour une version.
- Confier l'ordre du backlog à l'équipe ou au chef de projet. C'est le product owner qui ordonne ; les développeurs dimensionnent.
- Laisser un sponsor modifier directement le backlog. Le bon réflexe est de faire passer la demande par le product owner.
- Croire que les user stories remplacent tout dans un projet hybride. Certaines parties peuvent rester sous ligne de base de périmètre, d'autres sous backlog. L'article sur la combinaison de composants agiles et prédictifs illustre ce cas.
Voici une question d'entraînement, rédigée pour cette page. Une équipe livre une application de réservation en sprints de deux semaines. En pleine itération, la directrice commerciale demande au chef de projet d'ajouter une fonction de paiement fractionné, qu'un gros client exige. Que doit faire le chef de projet ? A : ajouter la fonction au sprint en cours ; B : demander aux développeurs d'estimer l'effort et de l'intégrer s'ils ont de la marge ; C : orienter la demande vers le product owner pour qu'il l'ajoute au product backlog et l'ordonne ; D : ouvrir une demande de changement formelle auprès du comité de pilotage.
La réponse attendue est C. Le sprint en cours est protégé par son objectif, et seul le product owner ordonne le backlog. B confond dimensionnement et priorisation ; D applique un mécanisme prédictif à un périmètre géré par backlog. Ce raisonnement, qui situe chaque rôle, vaut pour la plupart des questions agiles.
Pour vous entraîner sur ce type de scénario, la formation Project Management Professional (PMP) d'Atypix couvre les approches prédictives, agiles et hybrides, et le simulateur d'examen PMP permet de tester votre rythme. Si vous visez un approfondissement agile, la formation PMI-ACP traite le backlog plus en détail. À Dakar, les examens PMI peuvent se passer au centre d'examen Pearson VUE 90280 opéré par Atypix ; les sessions de la ville figurent sur la page des formations certifiantes à Dakar, et celles de Montréal sur la page des formations certifiantes à Montréal.
Questions fréquentes
Qui est responsable du product backlog ?
Le product owner. Selon le Scrum Guide, ce rôle formule l'objectif de produit, crée et communique les éléments, les ordonne et veille à ce que le backlog soit compris de tous. Le product owner peut déléguer une partie du travail, mais reste redevable. Les développeurs, eux, dimensionnent les éléments, et toute demande de modification passe par le product owner.
Un backlog doit-il contenir uniquement des user stories ?
Non. Le Scrum Guide parle d'éléments du product backlog sans imposer de format. Un backlog peut contenir des user stories, des corrections, du travail technique, des hypothèses à tester ou des exigences réglementaires. SAFe distingue d'ailleurs les user stories des enabler stories, qui couvrent l'architecture, l'infrastructure, l'exploration et la conformité. Le bon format est celui que les parties prenantes comprennent.
Quelle différence entre product backlog et sprint backlog ?
Le product backlog couvre tout le produit et appartient au product owner. Le sprint backlog ne couvre qu'un sprint : il réunit l'objectif du sprint, les éléments sélectionnés et le plan pour livrer l'incrément. Le Scrum Guide le décrit comme un plan par et pour les développeurs, qui l'ajustent au fil du sprint sans changer son objectif.
Comment prioriser un backlog dans un projet d'intelligence artificielle ?
Classez haut les éléments qui réduisent l'incertitude : vérifier la qualité des données, tester une prédiction sur un petit périmètre, mesurer l'acceptation par les utilisateurs. Formulez-les comme des hypothèses avec un critère de validation. La logique du WSJF s'applique : la réduction du risque fait partie du coût du retard, et un essai court passe souvent avant un développement long.
Quelle certification choisir pour approfondir la gestion du backlog ?
Cela dépend de votre rôle. Pour un product owner en équipe Scrum, la formation Professional Scrum Product Owner (PSPO I) prépare à l'examen en ligne de Scrum.org. Pour un chef de projet, le PMP ou le PMI-ACP couvrent le backlog dans un cadre plus large. Dans une organisation qui applique SAFe, la formation SAFe Product Owner et Product Manager vise ce contexte.