Product Backlog : guide complet, exemples et préparation au PSM I
La référence francophone sur le Product Backlog : refinement, priorisation, INVEST, DEEP, exemples concrets et questions PSM I corrigées.
28 min de lectureMis à jour le 29 juin 2026
Le Product Backlog est l'artéfact le plus visible de Scrum et l'un des sujets les plus testés au PSM I. C'est la seule source de travail de la Scrum Team. Ce guide couvre la définition officielle, la responsabilité du scrum product backlog, son refinement, la différence avec le sprint backlog, la priorisation, un product backlog example complet et plus de douze questions PSM I corrigées.
Qu'est-ce que le Product Backlog ?
Selon le Scrum Guide 2020, le Product Backlog est « une liste ordonnée et émergente de ce qui est nécessaire pour améliorer le produit ». Il est unique pour un produit donné, même lorsque plusieurs équipes y contribuent. Son engagement associé est le Product Goal, qui décrit l'état futur du produit que la Scrum Team cherche à atteindre.
Objectif : rendre transparent tout le travail à venir, permettre au Product Owner d'optimiser la valeur livrée et donner aux Developers une compréhension claire de ce qui doit être construit.
Pourquoi est-il indispensable ? Sans Product Backlog, la Scrum Team n'a pas de source unique de travail : la priorisation devient opaque, les arbitrages se font dans les couloirs et l'inspection en Sprint Review perd son sens. Le Product Backlog est l'outil qui rend Scrum empirique.
Qui est responsable du Product Backlog ?
La question « who owns the product backlog » est l'une des plus fréquentes au PSM I. La réponse est sans ambiguïté : le Product Owner. Lui seul décide.
Rôles autour du Product Backlog
Rôle
Responsabilité sur le Product Backlog
Limites
Product Owner
Crée, ordonne, clarifie, rend transparent le backlog. Seul à décider du contenu et de l'ordre.
Peut déléguer le travail, pas la redevabilité.
Developers
Participent au refinement, estiment, proposent des découpages techniques, suggèrent des PBI.
Ne décident ni du contenu ni de l'ordre.
Scrum Master
Coache le Product Owner sur les techniques de gestion du backlog et aide la Scrum Team à comprendre la nécessité d'éléments clairs et concis.
Aucune autorité sur le contenu ou l'ordre.
Parties prenantes
Proposent des besoins, donnent du feedback en Sprint Review.
Ne modifient pas directement le backlog.
En clair : le Scrum Master ne priorise jamais le Product Backlog, les Developers ne réordonnent jamais les PBI, et les parties prenantes ne peuvent pas imposer un ordre. Tout passe par le Product Owner.
Responsabilités autour du Product Backlog
Product Owner
Ordonne, clarifie et fait évoluer le Product Backlog. Seul redevable.
Developers
Raffinent, estiment, découpent techniquement. Ne décident pas de l'ordre.
Scrum Master
Facilite, coache le PO sur les techniques de gestion du backlog.
Comment fonctionne le Product Backlog ?
Le Product Backlog s'inscrit dans un flux continu, depuis la vision produit jusqu'à l'Increment livré en Sprint Review.
De la vision produit à l'Increment
À chaque Sprint, les Developers et le Product Owner sélectionnent les PBI prioritaires lors du Sprint Planning, les transforment en un Sprint Backlog assorti d'un Sprint Goal, produisent un Increment respectant la Definition of Done, et l'inspectent en Sprint Review. Le Product Backlog est ensuite mis à jour pour le Sprint suivant.
Qu'est-ce que le Product Backlog Refinement ?
Le product backlog refinement (ou raffinage) n'est pas un événement Scrum. C'est une activité continue, intégrée au flux de travail de la Scrum Team. Le Scrum Guide indique que le refinement occupe généralement moins de 10 % de la capacité des Developers. Pour aller plus loin, consultez notre guide dédié au raffinement du backlog et la liste détaillée des Product Backlog Items.
Cycle de Product Backlog Refinement
1. Découper
Casser les gros PBI en éléments plus petits.
2. Clarifier
Préciser le besoin, les critères, le contexte.
3. Estimer
Évaluer la taille avec les Developers.
4. Ordonner
Le PO réordonne en fonction de la valeur.
Activité continue, généralement ≤ 10 % de la capacité des Developers.
Qui participe ? Le Product Owner (toujours) et les Developers (souvent ensemble). Des parties prenantes peuvent être ponctuellement invitées pour clarifier un besoin.
Bonnes pratiques : maintenir 1 à 2 Sprints de PBI prêts en haut du backlog, garder une granularité fine en haut et grossière en bas, ne pas estimer ce qui n'est pas prioritaire, faire valider les découpages par les Developers.
Erreurs fréquentes : transformer le refinement en réunion fleuve hebdomadaire, embarquer toute l'équipe sur des PBI très lointains, ou laisser le Product Owner raffiner seul dans son coin.
Product Backlog vs Sprint Backlog
Product Backlog vs Sprint Backlog
Critère
Product Backlog
Sprint Backlog
Objectif
Améliorer le produit dans la durée.
Atteindre le Sprint Goal.
Responsable
Product Owner.
Developers.
Contenu
Tous les PBI connus.
PBI sélectionnés + plan + Sprint Goal.
Évolution
Émerge en permanence.
Émerge au cours du Sprint.
Durée de vie
Tant que le produit existe.
Le temps d'un Sprint.
Engagement
Product Goal.
Sprint Goal.
Visibilité
Toutes parties prenantes.
Principalement la Scrum Team.
Product Backlog vs Sprint Backlog en un coup d'œil
Product Backlog
Long terme · Product Owner
Tout le travail futur du produit
Engagement : Product Goal
Vit tant que le produit existe
Sprint Backlog
Un Sprint · Developers
PBI sélectionnés + plan + Sprint Goal
Engagement : Sprint Goal
Vit le temps d'un Sprint
Product Backlog vs Roadmap
Product Backlog vs Roadmap
Critère
Product Backlog
Roadmap
Granularité
PBI prêts à être pris en Sprint.
Thèmes, objectifs, jalons.
Horizon
Du Sprint en cours au long terme.
Trimestres ou plus.
Responsable
Product Owner.
Product Owner (souvent avec management produit).
Engagement
Product Goal.
Vision produit.
Stabilité
Émerge et change en permanence.
Plus stable, révisée par cycles.
Source Scrum Guide
Oui (artéfact).
Non (outil complémentaire).
Product Backlog vs Product Goal
Product Backlog vs Product Goal
Critère
Product Backlog
Product Goal
Nature
Artéfact (liste de travail).
Engagement (destination).
Forme
Liste ordonnée et émergente.
Phrase claire, mesurable.
Durée de vie
Aussi longtemps que le produit existe.
Le temps d'atteindre l'objectif.
Pluralité
Un par produit.
Un seul actif à la fois.
Responsable
Product Owner.
Product Owner.
Pour un guide complet, consultez la page pilier Product Goal.
Product Backlog vs Release Plan
Product Backlog vs Release Plan
Critère
Product Backlog
Release Plan
Statut Scrum
Artéfact officiel.
Pratique complémentaire.
Contenu
Tous les PBI ordonnés.
PBI projetés par release.
Granularité
PBI individuels.
Lots de PBI.
Évolution
Continue.
À chaque release ou jalon.
Public
Scrum Team + stakeholders.
Sponsors, clients, comités.
Comment prioriser un Product Backlog ?
Le Scrum Guide parle d'ordering plus que de prioritisation : le Product Owner ordonne les PBI pour maximiser la valeur. L'ordre n'est pas qu'une question de priorité, il intègre plusieurs dimensions.
Valeur métier : impact attendu pour les utilisateurs et l'entreprise (revenu, satisfaction, conformité…).
Risque : éléments incertains à valider tôt pour apprendre rapidement.
Dépendances : techniques ou organisationnelles, qui imposent un ordre minimum.
Coût / effort : éclairé par les estimations des Developers.
Cohérence avec le Product Goal : les PBI qui rapprochent du Product Goal passent devant.
Exemple concret : sur un SaaS B2B, un PBI « authentification SSO » peut passer devant un PBI « thème sombre » bien plus simple, parce qu'il débloque trois contrats entreprise (valeur métier élevée) malgré un effort important.
Critères INVEST des User Stories
Critères INVEST appliqués à un Product Backlog
Critère
Ce que ça veut dire
Anti-pattern fréquent
Independent
La story peut être livrée seule, sans dépendre d'une autre.
Stories en chaîne « A puis B puis C ».
Negotiable
Le « comment » reste discutable avec les Developers.
PBI rédigé comme une spec technique fermée.
Valuable
La story apporte une valeur perceptible.
PBI purement technique sans valeur utilisateur.
Estimable
Les Developers peuvent en estimer la taille.
Story trop floue ou trop large.
Small
Tient confortablement dans un Sprint.
Story qui mange la moitié d'un Sprint.
Testable
On sait dire si elle est faite et juste.
Aucun critère d'acceptation.
DEEP : critères d'un bon Product Backlog
Critères DEEP d'un Product Backlog sain
Critère
Ce que ça veut dire
Mesure rapide
Detailed appropriately
Les PBI du haut sont fins et clairs, ceux du bas restent grossiers.
Top 10 PBI prêts pour le prochain Sprint ?
Estimated
Les PBI du haut ont une taille (story points, t-shirt, etc.).
Top 1-2 Sprints estimés ?
Emergent
Le backlog évolue à chaque Sprint en fonction des apprentissages.
Au moins quelques modifications par Sprint ?
Prioritized
Le backlog est ordonné en permanence par le Product Owner.
Ordre clair, pas d'ex æquo cachés ?
Types de PBI : Epics, Stories, Bugs, Dette technique, Spikes
Le Scrum Guide ne définit aucun type de Product Backlog Item particulier — il parle simplement de « tout ce qui est nécessaire pour améliorer le produit ». En pratique, plusieurs types coexistent et chacun a sa place dans un Product Backlog sain.
Types de PBI courants
Type
Description
Place dans le backlog
Epic
PBI de grande taille, trop gros pour tenir dans un Sprint.
Bas / milieu du backlog, à découper avant de monter.
User Story
PBI fonctionnel décrit côté utilisateur (« En tant que… je veux… »).
Format dominant en haut du backlog.
Bug
Défaut détecté sur le produit existant.
Ordonné comme un PBI normal, en fonction de l'impact.
Dette technique
Refactoring, mise à jour de dépendances, amélioration de tests.
Sponsorisée par le PO, en fonction de l'impact long terme.
Spike
Effort d'investigation time-boxé pour lever une incertitude.
En tant que nouvel utilisateur, je peux créer mon compte en moins de 60 secondes.
5 pts
1
Très haute
Onboarding
En tant qu'utilisateur, je peux me connecter via Google.
3 pts
2
Haute
Réservation
En tant qu'utilisateur, je peux rechercher une disponibilité par date.
8 pts
3
Très haute
Réservation
En tant qu'utilisateur, je peux confirmer ma réservation et recevoir un email.
8 pts
4
Très haute
Paiement
En tant qu'utilisateur, je peux payer par carte bancaire.
13 pts
5
Haute
Compte
En tant qu'utilisateur, je peux consulter l'historique de mes réservations.
5 pts
6
Moyenne
Notifications
En tant qu'utilisateur, je reçois un rappel 24h avant la réservation.
5 pts
7
Moyenne
Compte
En tant qu'utilisateur, je peux supprimer mon compte (RGPD).
3 pts
8
Réglementaire
Thème
En tant qu'utilisateur, je peux activer un thème sombre.
5 pts
9
Faible
Note : les story points, epics et colonnes « valeur » ne sont pas imposés par le Scrum Guide. Ce sont des pratiques courantes compatibles avec Scrum.
Trois exemples de backlog par domaine
Pour illustrer comment un Product Backlog se structure en Epic → Feature → User Story → Sprint, voici trois extraits réalistes dans des contextes différents.
Exemple concret : Application bancaire mobile
Epic
Feature
User Story
Sprint cible
Onboarding KYC
Vérification d'identité
Je peux scanner ma pièce d'identité depuis l'app.
Sprint 1
Comptes
Solde en temps réel
Je vois le solde actualisé de mes comptes en moins de 2 s.
Sprint 2
Virements
Virement SEPA instantané
Je peux envoyer un virement instantané à un bénéficiaire enregistré.
Sprint 3
Sécurité
Authentification forte
Je valide une opération sensible avec la biométrie.
Sprint 3
Support
Chat sécurisé
Je peux contacter un conseiller depuis l'app.
Sprint 5
Exemple concret : Plateforme e-commerce
Epic
Feature
User Story
Sprint cible
Catalogue
Recherche
Je peux filtrer les produits par catégorie et prix.
Sprint 1
Panier
Gestion panier
Je peux modifier les quantités et voir le total mis à jour.
Sprint 1
Checkout
Paiement CB
Je peux payer en CB en moins de 3 étapes.
Sprint 2
Checkout
Paiement en 3 fois
Je peux payer en 3 fois sans frais au-dessus de 100 €.
Sprint 3
Compte
Suivi de commande
Je peux suivre l'état de ma commande en temps réel.
Sprint 4
Exemple concret : Application mobile de fitness
Epic
Feature
User Story
Sprint cible
Profil
Création de profil
Je peux renseigner mes objectifs et mon niveau.
Sprint 1
Entraînement
Plans guidés
Je peux démarrer une séance guidée pas à pas.
Sprint 2
Suivi
Statistiques
Je vois mes progrès hebdomadaires sous forme de graphiques.
Le Product Backlog ne vit pas seul : il s'inscrit dans l'écosystème complet des artéfacts et engagements Scrum. Le tableau ci-dessous synthétise leurs différences pour le PSM I.
Artéfacts et engagements Scrum comparés
Artéfact / Engagement
Responsable
Durée
Objectif
Engagement associé
Visibilité
Product Backlog
Product Owner
Vie du produit
Améliorer le produit
Product Goal
Toutes parties prenantes
Sprint Backlog
Developers
Un Sprint
Atteindre le Sprint Goal
Sprint Goal
Scrum Team
Increment
Scrum Team
Cumulatif
Livrer de la valeur utilisable
Definition of Done
Stakeholders
Product Goal
Product Owner
Long terme
État futur du produit
—
Toutes parties prenantes
Sprint Goal
Scrum Team
Un Sprint
Objectif unique du Sprint
—
Scrum Team + stakeholders
Exemple SaaS B2B : du Product Goal au PBI
Voici comment un SaaS B2B (plateforme de gestion de notes de frais) structure son Product Backlog autour d'un Product Goal très concret : « Réduire de 50 % le temps de validation d'une note de frais en 6 mois ».
Exemple concret : SaaS B2B — Notes de frais
Epic
Feature
User Story
Sprint cible
Capture
OCR ticket
Je scanne un ticket et les champs (montant, TVA, date) sont préremplis.
Sprint 1
Capture
Import bancaire
Je connecte ma carte d'entreprise pour importer les transactions.
Sprint 2
Validation
Workflow manager
Mon manager valide ou refuse la note en un clic depuis l'email.
Sprint 2
Validation
Règles automatiques
Les notes < 50 € respectant la politique sont validées automatiquement.
Sprint 3
Comptabilité
Export DSN
Le comptable exporte les validations vers le logiciel paie en un clic.
Sprint 4
Conformité
Archivage probant
Les justificatifs sont archivés conformément à la norme NF Z42-013.
Sprint 5
Adoption
Onboarding
Un nouvel utilisateur produit sa première note en moins de 3 minutes.
Sprint 6
Cycle de vie d'un Product Backlog Item
Un PBI ne naît pas « prêt » : il traverse plusieurs états avant d'arriver dans un Sprint, puis d'être livré dans un Increment.
Cycle de vie d'un PBI
Bonnes pratiques de gestion d'un Product Backlog
Maintenir 1 à 2 Sprints de PBI prêts en haut du backlog, pas davantage : trop de préparation devient du gaspillage.
Limiter le refinement à ~10 % de la capacité des Developers ; au-delà, c'est souvent un signal que le PO arrive seul, sans préparation.
Rendre le backlog public aux parties prenantes par défaut, pas sur demande — la transparence est un pilier de Scrum.
Relier chaque PBI au Product Goal ; si la relation est floue, questionner la place du PBI dans le backlog.
Séparer estimation et engagement : une estimation n'est pas une promesse de livraison. Seul l'Increment livré en Sprint Review compte.
Inviter régulièrement les Developers dans la conversation d'ordonnancement : leurs contraintes techniques sont une donnée d'entrée du PO.
Erreurs fréquentes
Backlog figé : si rien ne bouge entre deux Sprints, le Product Owner n'optimise plus la valeur — anti-pattern.
Backlog non ordonné : « tout est prioritaire » = rien n'est prioritaire. Le Product Backlog doit toujours être ordonné.
Backlog géré par plusieurs personnes : un seul Product Owner par produit. Sinon, conflits d'ordre et perte de responsabilité.
Backlog sans Product Goal : difficile d'ordonner sans cap. Le Product Goal est l'engagement du Product Backlog.
Confusion avec le Sprint Backlog : les Developers gèrent le Sprint Backlog, pas le Product Backlog. Voir notre comparatif Sprint Backlog vs Product Backlog.
Refinement transformé en réunion obligatoire : le refinement est une activité continue, pas un événement Scrum.
Questions PSM I sur le Product Backlog
Référence officielle
Le Product Backlog est l'un des trois artéfacts décrits dans le Scrum Guide, document de référence publié et maintenu par Ken Schwaber et Jeff Sutherland. Depuis la version 2020, son engagement officiel est le Product Goal.
C'est cette définition qui sert de référence à la certification PSM I proposée par Scrum.org. Les questions de l'examen s'appuient strictement sur la formulation et l'esprit du Scrum Guide. Pour cette raison, nos contenus reprennent fidèlement la terminologie officielle sans reproduire d'extraits protégés.
Scrum, Scrum Guide et PSM I sont des marques de Scrum.org. Ce site est une ressource indépendante de préparation, sans affiliation officielle.
Questions fréquentes
Qu'est-ce qu'un Product Backlog ?+
Le Product Backlog est une liste ordonnée, émergente et unique de tout ce qui est nécessaire pour améliorer le produit. C'est la seule source de travail entrant pour la Scrum Team. Il évolue en permanence pour refléter la compréhension actuelle du produit, du marché et des utilisateurs.
Qui possède le Product Backlog ?+
Le Product Owner est seul responsable de la gestion du Product Backlog : son contenu, son ordre et sa transparence. D'autres personnes peuvent contribuer (Developers, parties prenantes), mais le Product Owner reste la seule personne redevable.
Quelle est la différence entre Product Backlog et Sprint Backlog ?+
Le Product Backlog regroupe l'ensemble du travail futur connu pour le produit et appartient au Product Owner. Le Sprint Backlog est un sous-ensemble sélectionné pour un Sprint, complété par un plan de livraison, et appartient aux Developers. L'un est long terme, l'autre couvre un Sprint.
Qui peut modifier le Product Backlog ?+
Seul le Product Owner peut décider de l'ajout, du retrait ou de l'ordre des éléments. Les Developers et parties prenantes peuvent proposer des changements, mais aucun n'est appliqué sans accord du Product Owner.
Le Scrum Master peut-il prioriser le Product Backlog ?+
Non. Le Scrum Master n'a aucune autorité sur le contenu ou l'ordre du Product Backlog. Il coache le Product Owner sur les techniques de gestion du backlog, mais la décision finale revient toujours au Product Owner.
Le Product Backlog est-il figé ?+
Non, jamais. Le Product Backlog est par nature émergent : il évolue à mesure que le produit, le marché et la compréhension de la Scrum Team progressent. Un backlog figé est un anti-pattern Scrum.
Que contient un Product Backlog ?+
Des Product Backlog Items (PBI) : nouvelles fonctionnalités, améliorations, corrections, dette technique, travaux d'expérimentation. Chaque PBI doit, à terme, comporter une description, un ordre, une estimation et — pour ceux du haut du backlog — suffisamment de détails pour être pris dans un Sprint.
À quoi sert le Product Backlog Refinement ?+
Le refinement (ou raffinage) consiste à découper, clarifier, estimer et ordonner les Product Backlog Items. Il est continu, mené par le Product Owner avec les Developers, et limite généralement 10 % de leur capacité. Son but : rendre les PBI du haut du backlog prêts pour un futur Sprint.
Quelle est la différence entre Product Backlog et Roadmap ?+
La Roadmap décrit la direction stratégique du produit (thèmes, objectifs, horizons de plusieurs mois). Le Product Backlog liste le travail concret et ordonné à réaliser pour avancer dans cette direction. La Roadmap inspire le Product Backlog ; elle ne le remplace pas.
Quelle est la différence entre Product Backlog et Product Goal ?+
Le Product Goal est l'engagement (la destination) associé au Product Backlog. Le Product Backlog est l'artéfact qui contient le travail pour atteindre ce Product Goal. Un seul Product Goal actif à la fois par Product Backlog.
Quelle est la différence entre Product Backlog et Release Plan ?+
Le Release Plan est une projection : quels PBI seront probablement livrés dans quelle Release, à partir de la vélocité et de l'ordre du backlog. Il dérive du Product Backlog ; il n'est pas un artéfact Scrum officiel.
Qu'est-ce que la règle INVEST pour une User Story ?+
INVEST signifie Independent, Negotiable, Valuable, Estimable, Small, Testable. C'est une heuristique pour évaluer la qualité d'une User Story : indépendante, négociable, à valeur, estimable, petite, testable.
Qu'est-ce que la règle DEEP pour un Product Backlog ?+
DEEP signifie Detailed appropriately, Estimated, Emergent, Prioritized. Un bon Product Backlog est détaillé au bon niveau (plus en haut, moins en bas), estimé en haut, émergent et toujours ordonné.
Les bugs et la dette technique vont-ils dans le Product Backlog ?+
Oui. Tout travail nécessaire à l'amélioration du produit appartient au Product Backlog, y compris les bugs, la dette technique, les spikes et les améliorations non fonctionnelles.
Qu'est-ce qu'un Epic dans le Product Backlog ?+
Un Epic est un Product Backlog Item de grande taille, généralement trop gros pour tenir dans un Sprint. Il est ensuite découpé en User Stories plus petites lors du refinement. Epic n'est pas un terme officiel du Scrum Guide, mais une convention répandue.
Quels attributs un PBI doit-il avoir selon le Scrum Guide ?+
Le Scrum Guide cite quatre attributs : description, ordre, taille (size), et — pour les PBI proches d'être pris dans un Sprint — la valeur. Les autres attributs (critères d'acceptation, story points, propriétaire) sont des pratiques utiles mais non imposées.
Qui estime les Product Backlog Items ?+
Les Developers, car ce sont eux qui réalisent le travail. Le Product Owner peut influencer la conversation autour de la valeur, mais l'effort relève des Developers.
Un produit développé par plusieurs équipes a-t-il plusieurs Product Backlogs ?+
Non. Le Scrum Guide impose un Product Backlog unique par produit, quel que soit le nombre d'équipes Scrum, avec un seul Product Owner et un seul Product Goal.
Un PBI rejeté en Sprint Review est-il automatiquement reporté ?+
Non. Il retourne dans le Product Backlog où le Product Owner décide librement de son nouvel ordre, qui peut être très bas ou très haut selon les apprentissages de la Review.
Que valent les story points dans Scrum ?+
Les story points sont une pratique d'estimation populaire mais non imposée par le Scrum Guide, qui parle seulement de « size ». T-shirt sizing, heures idéales ou nombre de tickets sont d'autres approches valides.
Préparez votre certification PSM I dans des conditions proches de l'examen officiel
Entraînez-vous avec des examens blancs, des questions difficiles et des corrections détaillées.
