Le Sprint Backlog et le Product Backlog sont les deux artefacts Scrum les plus souvent confondus — et cette confusion est une mine d'or pour les questions pièges du PSM I. Les noms se ressemblent, ils contiennent tous deux des items, et ils sont liés par le Sprint Planning. Pourtant, ils ne couvrent pas le même horizon, n'ont pas le même propriétaire et ne servent pas le même objectif.
Le Product Backlog est la liste de tout ce que le produit pourrait devenir : c'est la projection long terme du Product Owner. Le Sprint Backlog, lui, est le plan détaillé d'un seul Sprint : un sous-ensemble du Product Backlog choisi par les Developers, complété par un Sprint Goal et un plan d'action concret.
Cette page vous donne la réponse précise (tableau comparatif, schéma, cartes, exemple bancaire, FAQ) à la question « sprint backlog vs product backlog », et explique pourquoi elle est si fréquente à l'examen Scrum PSM I.
Tableau comparatif Sprint Backlog vs Product Backlog
Ce tableau résume en un coup d'œil les onze critères qui séparent les deux artefacts selon le Scrum Guide 2020.
| Critère | Product Backlog | Sprint Backlog |
|---|---|---|
| Définition | Liste ordonnée et émergente de tout ce qui pourrait être nécessaire au produit. | Sprint Goal + items sélectionnés + plan concret pour livrer l'Increment. |
| Objectif | Représenter la valeur potentielle du produit. | Rendre visible le travail engagé pour le Sprint Goal. |
| Horizon | Long terme (mois → années) ; vit aussi longtemps que le produit. | Court terme : une seule Sprint timebox (1 à 4 semaines). |
| Responsable | Product Owner (accountability unique). | Developers (accountability unique). |
| Contenu | Product Backlog Items : features, user stories, bugs, dette technique, spikes. | Sous-ensemble du Product Backlog + Sprint Goal + plan / tâches. |
| Évolution | Continue : refinement permanent, jamais figée. | Quotidienne pendant le Sprint, par les Developers. |
| Moment de création | Dès le démarrage du produit, avant le premier Sprint. | Pendant le Sprint Planning, en début de chaque Sprint. |
| Moment de mise à jour | À tout moment, lors du refinement avec la Scrum Team. | Tous les jours, notamment au Daily Scrum. |
| Lien avec le Sprint Goal | Source des items qui rendront le Sprint Goal possible. | Contient le Sprint Goal ; c'est son engagement officiel. |
| Engagement attaché | Product Goal (objectif produit à moyen / long terme). | Sprint Goal (objectif unique du Sprint). |
| Valeur pour l'équipe Scrum | Donne la direction stratégique du produit. | Donne la visibilité opérationnelle du Sprint en cours. |
Product Backlog & Sprint Backlog : définitions côte à côte
Product Backlog
Définition officielle (simplifiée). Liste ordonnée et émergente de tout ce qui est connu comme nécessaire pour améliorer le produit. C'est la seule source des travaux entrepris par la Scrum Team.
Responsable. Le Product Owner : il ordonne les items, les rend transparents et collabore avec la Scrum Team pour les raffiner.
Objectif. Maximiser la valeur livrée par la Scrum Team. L'engagement associé est le Product Goal.
Exemple. Pour une application bancaire : connexion, virement, historique, notifications, profil, support biométrie, scan de chèques, multi-comptes, dette technique sur le module de paiement…
Sprint Backlog
Définition officielle (simplifiée). Composé du Sprint Goal, des Product Backlog Items sélectionnés pour le Sprint et d'un plan concret pour les livrer en tant qu'Increment.
Responsables. Les Developers uniquement. Eux seuls construisent et mettent à jour le Sprint Backlog.
Objectif. Rendre visible le travail nécessaire pour atteindre le Sprint Goal et produire un Increment conforme à la Definition of Done.
Exemple. Pour le Sprint « Permettre à un client de se connecter de manière sécurisée » : écran de login, API d'authentification, tests automatisés, correction des bugs de saisie, instrumentation analytics.
Schéma : du Product Vision à l'Increment
Le Product Backlog et le Sprint Backlog ne s'opposent pas — ils s'enchaînent. Le Product Backlog alimente le Sprint Planning, qui produit le Sprint Backlog, qui guide le développement, qui livre l'Increment.
Les blocs bleus correspondent aux deux artefacts comparés ; le bloc vert est l'Increment livré au Sprint.
Les principales différences
Pour mémoriser durablement la distinction, on peut la décomposer en sept différences fondamentales — toutes testées au PSM I.
Le Product Backlog couvre la totalité de la vie du produit. Le Sprint Backlog n'existe que pendant un seul Sprint et disparaît à sa clôture.
Le Product Owner est seul responsable du Product Backlog. Les Developers sont seuls responsables du Sprint Backlog. Le Scrum Master n'en possède aucun.
Le Product Backlog liste tout ce qui pourrait améliorer le produit. Le Sprint Backlog ne liste que ce que les Developers ont sélectionné pour ce Sprint, plus le Sprint Goal et le plan d'action.
Le Product Backlog évolue en continu (refinement). Le Sprint Backlog évolue quotidiennement, mais dans la limite du Sprint Goal.
Le Product Backlog rend le Sprint Goal possible (via les items choisis). Le Sprint Backlog contient le Sprint Goal — c'est son engagement officiel.
Seul le Product Owner ordonne le Product Backlog. Dans le Sprint Backlog, les Developers choisissent l'ordre d'exécution des tâches.
Le Product Backlog est mis à jour à tout moment lors du refinement. Le Sprint Backlog est mis à jour au moins chaque jour, notamment au Daily Scrum.
Exemple concret : une application bancaire
Imaginons une équipe Scrum qui développe l'application mobile d'une banque en ligne. Voici comment se traduit la différence entre les deux artefacts dans la vraie vie.
Product Backlog (extrait)
- Connexion sécurisée (login / mot de passe + biométrie)
- Virement instantané SEPA
- Historique des opérations avec filtres
- Notifications push (mouvements, alertes de seuil)
- Profil utilisateur et coordonnées
- Scan de chèques par appareil photo
- Multi-comptes (courant, épargne, crédit)
- Réduction de la dette technique sur le module paiement
- Refonte du parcours d'inscription
→ Ordonné par le Product Owner, jamais figé, partagé avec toute la Scrum Team.
Sprint Backlog — Sprint 1
Sprint Goal
« Permettre à un client existant de se connecter de manière sécurisée à son application mobile. »
Items sélectionnés + plan
- Écran de login (UI + validation)
- API d'authentification + JWT
- Tests automatisés login (unitaires + E2E)
- Correction des bugs ouverts sur la saisie
- Mise en place de l'analytics de connexion
→ Construit et mis à jour par les Developers, vivant pendant 14 jours, puis remplacé au Sprint suivant.
Lecture clé : tous les items du Sprint Backlogproviennent du Product Backlog, mais l'inverse n'est pas vrai. Et la connexion sécurisée reste un PBI au niveau produit ; ce qui change, c'est qu'elle est désormais en cours de livraison.
Erreurs fréquentes (et pourquoi elles tombent au PSM I)
Pourquoi cette différence est cruciale au PSM I
Sur les 80 questions du PSM I, plusieurs portent directement ou indirectement sur la distinction Sprint Backlog vs Product Backlog. L'examen aime particulièrement piéger les candidats sur :
- La responsabilité : qui possède quoi ? La bonne réponse repose toujours sur « PO → Product Backlog » et « Developers → Sprint Backlog ».
- Les engagements : Product Goal pour le Product Backlog, Sprint Goal pour le Sprint Backlog, Definition of Done pour l'Increment. Inverser l'un des trois est une perte de point garantie.
- Les modifications en cours de Sprint : le Product Backlog évolue librement ; le Sprint Backlog évolue aussi, mais sans compromettre le Sprint Goal.
- Le refinement : il porte sur le Product Backlog, pas sur le Sprint Backlog. Une question typique demande qui peut décider d'ajouter un item au Sprint, et la bonne réponse est toujours « les Developers, en collaboration avec le Product Owner ».
Astuce mémo : Product Backlog = le QUOI à long terme du Product Owner. Sprint Backlog = le COMMENT à court terme des Developers.
Origine et évolution dans le Scrum Guide
Pour bien saisir la différence entre Sprint Backlog et Product Backlog, il faut remonter à l'histoire même du Scrum Guide, co-écrit par Ken Schwaber et Jeff Sutherland. Dans les premières versions (2010, 2011), le Sprint Backlog était décrit avant tout comme une liste de tâches techniques tirées d'items du Product Backlog. La frontière entre les deux artefacts était encore floue, et beaucoup d'équipes traitaient le Sprint Backlog comme une simple « to-do list » dérivée.
La version 2020 du Scrum Guide a profondément clarifié les choses en introduisant la notion d'engagement (commitment) attaché à chaque artefact. Désormais, chaque artefact Scrum porte une information de transparence et un engagement explicite :
- Product Backlog → engagement : le Product Goal.
- Sprint Backlog → engagement : le Sprint Goal.
- Increment → engagement : la Definition of Done.
Ce changement n'est pas cosmétique. Il a une conséquence directe sur la distinction Sprint Backlog vs Product Backlog : les deux artefacts ne sont plus seulement « deux listes d'items », ils portent chacun un objectif différent. Le Product Backlog devient un outil d'alignement stratégique autour d'un Product Goal ; le Sprint Backlog devient un outil de focus tactique autour d'un Sprint Goal. Les questions PSM I postérieures à 2020 testent systématiquement cette nouvelle lecture.
Autre conséquence : la disparition de la cérémonie formelle de « Backlog Grooming ». Le Product Backlog Refinement est désormais une activité continue, jamais imposée comme un événement officiel. Il porte exclusivement sur le Product Backlog — jamais sur le Sprint Backlog, qui appartient aux Developers et ne se « raffine » pas, il se met à jour.
Anatomie détaillée du Product Backlog
Le Product Backlog n'est pas une simple liste à puces. C'est un artefact vivant qui obéit à plusieurs critères de qualité reconnus par la communauté Scrum mondiale.
Le critère DEEP
L'acronyme DEEP, popularisé par Roman Pichler et Mike Cohn, décrit un Product Backlog en bonne santé :
- D — Detailed appropriately : plus un item est haut dans le backlog, plus il est détaillé. Les items du bas peuvent rester volontairement flous.
- E — Emergent : le contenu évolue continuellement en fonction des apprentissages, des retours utilisateurs et des changements de marché.
- E — Estimated : les items en haut du backlog disposent d'une estimation (story points, t-shirt sizing, ou simplement « plus grand / plus petit que »).
- P — Prioritized / Ordered : l'ordre est décidé par le Product Owner. Le Scrum Guide 2020 parle d'« ordered » plutôt que « prioritized » pour insister sur la dimension séquentielle, pas seulement la valeur business.
Cette pyramide d'attention est cruciale : les items proches du sommet sont prêts à entrer dans un Sprint Backlog. Les items du bas restent à l'état d'épics ou de simples lignes d'intention. C'est précisément le travail de refinement de faire descendre les items « importants » vers le haut du backlog en les découpant et en les précisant.
Le critère INVEST pour les items
Bill Wake a proposé l'acronyme INVEST pour qualifier un bon Product Backlog Item, en particulier sous forme de User Story :
- I — Independent : indépendant des autres, pour pouvoir être priorisé librement.
- N — Negotiable : négociable, pas figé dans le marbre.
- V — Valuable : porteur de valeur pour l'utilisateur ou pour le produit.
- E — Estimable : suffisamment compris pour être estimé.
- S — Small : assez petit pour tenir dans un Sprint.
- T — Testable : vérifiable via des critères d'acceptation clairs.
Un PBI qui ne respecte pas INVEST n'est pas prêt à rejoindre un Sprint Backlog. Le Sprint Planning butera dessus, les Developers ne pourront pas s'engager, et le risque d'échec du Sprint Goal augmente mécaniquement. C'est la raison d'être de la notion de Definition of Ready que beaucoup d'équipes utilisent (même si elle n'est pas dans le Scrum Guide).
L'ordering, prérogative absolue du Product Owner
Le Product Owner est la seule personne habilitée à ordonner le Product Backlog. Ni le Scrum Master, ni les Developers, ni les stakeholders ne peuvent imposer un ordre. Les critères utilisés sont multiples : valeur business, risque, dépendance, coût d'opportunité, ROI, learning value… mais le choix final revient au PO. C'est l'un des fondements de son accountability.
Anatomie détaillée du Sprint Backlog
Le Scrum Guide 2020 décrit le Sprint Backlog comme l'addition de trois composantes indissociables. Cette structure tripartite est souvent mal comprise, et elle est une source classique de questions PSM I.
L'objectif unique du Sprint. Il donne du sens à l'effort, oriente les arbitrages quotidiens et constitue l'engagement du Sprint Backlog. Sans Sprint Goal, le Sprint Backlog n'est qu'une liste de tâches.
Le sous-ensemble du Product Backlog que les Developers ont jugé réaliste pour atteindre le Sprint Goal compte tenu de leur capacité et de la Definition of Done.
La décomposition technique : tâches, sous-tâches, architectures, tests, déploiements. Ce plan évolue chaque jour au gré des apprentissages.
Trop d'équipes ne formalisent que la troisième composante (les tâches techniques) et oublient les deux premières. Résultat : le Sprint Backlog devient un « tableau Jira » sans direction, impossible à inspecter lors du Daily Scrum, et invisible pour les stakeholders qui voudraient comprendre pourquoi on travaille sur ces items.
La transparence avant tout
Le Sprint Backlog doit être visible et accessible à tous ceux qui peuvent influencer ou être influencés par le Sprint, y compris les stakeholders externes. Un Sprint Backlog caché dans un fichier privé du tech lead viole le pilier de transparence de Scrum. Tableau physique, board Jira partagé, dashboard Notion, peu importe le support — l'accès doit être ouvert.
L'engagement n'est pas la quantité d'items
Erreur classique en entreprise : confondre « engagement » avec « tous les items prévus seront livrés ». L'engagement attaché au Sprint Backlog n'est pas de livrer 100 % des items, c'est d'atteindre le Sprint Goal. Si l'équipe atteint le Sprint Goal avec 80 % des items, le Sprint est réussi. Si elle livre 100 % des items sans atteindre le Sprint Goal, c'est un échec — au sens Scrum strict.
Cycle de vie comparé
Une autre façon de comprendre la différence entre les deux artefacts consiste à observer leur durée de vie et leurs moments de transformation.
| Étape du cycle de vie | Product Backlog | Sprint Backlog |
|---|---|---|
| Naissance | Avant le tout premier Sprint, dès la formulation du Product Goal. | À la fin de chaque Sprint Planning, jamais avant. |
| Vie quotidienne | Refinement continu, ajout / suppression / re-priorisation par le PO. | Mises à jour quotidiennes par les Developers, notamment au Daily Scrum. |
| Source des entrées | Stakeholders, marché, retours utilisateurs, vision du PO. | Product Backlog (tirage par les Developers en Sprint Planning). |
| Source des sorties | Items « pris » pour devenir partie d'un Sprint Backlog. | Increment livré + items non terminés renvoyés au Product Backlog. |
| Mort | Quand le produit est arrêté ou pivoté radicalement. | À la fin du Sprint (par la Sprint Review puis la Retrospective). |
| Continuité | Persistant. Survit aux Sprints, aux PO successifs, aux refontes. | Éphémère. Recréé à zéro à chaque Sprint Planning. |
Cette différence de cycle de vie a une conséquence pratique : on archive rarement un Product Backlog (on l'enrichit), mais on archive systématiquement un Sprint Backlog à la clôture du Sprint. Beaucoup d'outils (Jira, Azure DevOps) automatisent ce comportement.
Outils et représentations concrètes
Le Scrum Guide reste volontairement silencieux sur les outils. En pratique, les équipes Scrum francophones utilisent un éventail de supports qui n'ont pas tous les mêmes forces selon l'artefact concerné.
| Outil | Product Backlog | Sprint Backlog |
|---|---|---|
| Jira | Très adapté : épics, stories, ordering par rang, refinement collaboratif. | Excellent : board Scrum avec colonnes To Do / In Progress / Done. |
| Azure DevOps | Adapté : backlog hiérarchisé en Features → User Stories → Tasks. | Excellent : sprint board + burndown intégré. |
| Trello | Acceptable pour les petits backlogs (≤ 100 items). | Très adapté : un board par Sprint, simple et visuel. |
| Notion | Bon pour la collaboration documentaire et le refinement asynchrone. | Adapté avec une base de données dédiée au Sprint en cours. |
| Tableau physique | Inadapté : trop d'items, mise à jour fastidieuse. | Excellent : visibilité maximale, mise à jour rituelle au Daily Scrum. |
| Excel / Google Sheets | Convient en démarrage de produit ou pour les très petits backlogs. | À éviter : peu de visibilité, pas de workflow Kanban natif. |
Règle pratique : le bon outil est celui qui permet à toute la Scrum Team d'inspecter et d'adapter en temps réel. Si la mise à jour devient une corvée que l'équipe « fait pour le Scrum Master » plutôt que pour elle-même, c'est le signe qu'il faut simplifier.
Métriques associées à chaque backlog
Les deux artefacts génèrent des métriques différentes parce qu'ils répondent à des questions différentes. Confondre les métriques est une erreur fréquente qui mène à du fake agile en entreprise.
Métriques du Product Backlog
- Release Burnup : progression cumulée du travail terminé par rapport au périmètre total (variable) d'une version produit.
- Time-to-Market : temps moyen entre l'ajout d'un PBI au backlog et sa mise en production.
- Backlog Health : nombre d'items « Ready » en haut du backlog. Une équipe saine garde 2 à 3 Sprints d'items prêts en avance.
- Cost of Delay : estimation économique du retard d'un item pour aider à l'ordering.
Métriques du Sprint Backlog
- Sprint Burndown : travail restant sur le Sprint en cours, mis à jour quotidiennement par les Developers.
- Velocity : somme des story points terminés par Sprint, utile en moyenne glissante sur 3 à 5 Sprints.
- Cycle Time : durée moyenne entre le début et la fin d'un PBI dans le Sprint.
- Sprint Goal Success Rate : pourcentage de Sprints où le Sprint Goal a été atteint. Métrique la plus honnête sur la santé d'une équipe.
Anti-pattern à éviter : utiliser la velocity du Sprint Backlog comme outil de pilotage stratégique du Product Backlog. La velocity est une métrique d'équipe et de capacité, pas un indicateur de valeur. Le Product Owner pilote la valeur avec les métriques de Product Backlog (Time-to-Market, Cost of Delay), pas avec la velocity.
Cas particuliers : bugs, dette technique, urgences
La théorie est claire, mais la réalité des équipes Scrum est rarement aussi propre. Voici comment traiter les cas limites les plus fréquents.
Les bugs détectés en production
Un bug remonté en production pendant un Sprint en cours ne va pas automatiquement dans le Sprint Backlog. Le Product Owner l'ajoute au Product Backlog et décide de sa priorité. Si le bug est critique (production cassée, perte de revenu), il peut être tiré dans le Sprint en cours — mais seulement avec l'accord des Developers et sans compromettre le Sprint Goal. Sinon, il attend le prochain Sprint Planning.
La dette technique
La dette technique est un Product Backlog Item comme un autre. Elle est ordonnée par le Product Owner en collaboration avec les Developers, qui sont les seuls à pouvoir en évaluer la gravité. Le Sprint Backlog peut contenir des items de dette technique si ceux-ci contribuent au Sprint Goal (par exemple : refactor du module de paiement avant d'y ajouter une nouvelle feature).
Les spikes (exploration technique)
Un spike est un PBI à durée limitée (timeboxed) dont le but est de produire de la connaissance, pas du code livrable. Il vit d'abord dans le Product Backlog, puis rejoint un Sprint Backlog si l'apprentissage est nécessaire pour atteindre le Sprint Goal ou pour préparer un futur Sprint.
Les urgences réglementaires ou sécurité
Une faille de sécurité critique peut justifier l'annulation pure et simple du Sprint en cours par le Product Owner (seule personne habilitée à cancel un Sprint). Le Sprint Backlog est alors dissous, un nouveau Sprint démarre avec un Sprint Goal adapté. C'est rare, mais le Scrum Guide le prévoit explicitement.
Les demandes des stakeholders en cours de Sprint
Les stakeholders ne parlent qu'au Product Owner. Ils ne modifient jamais directement le Sprint Backlog. Le Scrum Master est garant de cette frontière : il protège les Developers des interruptions et oriente les demandes vers le Product Backlog pour le refinement.
Comparaison avec d'autres frameworks
La distinction Sprint Backlog / Product Backlog existe sous d'autres noms dans les frameworks adjacents. Comprendre ces équivalents aide à éviter les confusions en environnement hybride.
| Framework | Équivalent Product Backlog | Équivalent Sprint Backlog |
|---|---|---|
| Scrum (référence) | Product Backlog (Product Owner). | Sprint Backlog (Developers) + Sprint Goal. |
| SAFe (Scaled Agile) | Program Backlog, Solution Backlog, Portfolio Backlog (multi-niveaux). | Team Iteration Backlog + PI Objectives. |
| Kanban | Backlog en amont du board (illimité, non timeboxé). | Colonnes du board limitées par WIP (Work In Progress). |
| LeSS (Large-Scale Scrum) | Un seul Product Backlog partagé entre toutes les équipes. | Un Sprint Backlog par équipe Scrum. |
| Scrumban | Backlog produit hérité de Scrum. | Board Kanban avec timebox optionnelle. |
Point clé pour le PSM I : l'examen ne porte que sur le Scrum Guide 2020. Les notions SAFe, LeSS ou Kanban peuvent être utiles dans votre quotidien professionnel, mais elles ne doivent pas influencer vos réponses à l'examen. Si une question évoque « Program Backlog » ou « PI Planning », c'est soit hors-sujet, soit un piège.
10 questions PSM I types corrigées
Voici dix questions inspirées du format réel du PSM I, avec leur réponse correcte et l'explication pédagogique correspondante.
Q1. Qui ajoute des items au Sprint Backlog pendant le Sprint ?
Réponse : les Developers, en collaboration avec le Product Owner si nécessaire. Le Product Owner ne peut pas imposer l'ajout. Le Scrum Master ne décide jamais.
Q2. Quel artefact contient le Sprint Goal ?
Réponse : le Sprint Backlog. Le Sprint Goal est l'engagement attaché au Sprint Backlog, pas un artefact séparé.
Q3. Le Product Backlog peut-il être modifié pendant un Sprint ?
Réponse : oui. Le Product Owner peut ajouter, retirer, réordonner des items à tout moment. Cela n'affecte pas le Sprint en cours (le Sprint Backlog est protégé par le Sprint Goal).
Q4. Qui est responsable de la transparence du Sprint Backlog ?
Réponse : les Developers. Ils possèdent l'artefact, ils en garantissent la transparence. Le Scrum Master coache, mais ne se substitue pas.
Q5. Combien d'items doit contenir un Sprint Backlog ?
Réponse : aucun nombre imposé. Les Developers déterminent eux-mêmes la quantité réaliste pour atteindre le Sprint Goal compte tenu de leur capacité.
Q6. Que devient un item du Sprint Backlog non terminé ?
Réponse : il retourne au Product Backlog. Le Product Owner décide ensuite s'il reste prioritaire pour un futur Sprint. Il n'est jamais reporté automatiquement.
Q7. Le Sprint Backlog peut-il être supprimé ?
Réponse : oui, en cas d'annulation du Sprint. Seul le Product Owner a l'autorité d'annuler un Sprint. Le Sprint Backlog est alors dissous.
Q8. Le Product Owner peut-il refuser un item au Sprint Review ?
Réponse : oui. Si un item ne respecte pas la Definition of Done, il ne fait pas partie de l'Increment et retourne au Product Backlog. La Sprint Review reste un événement de collaboration, pas une approbation formelle.
Q9. Qui priorise le Sprint Backlog ?
Réponse : les Developers. Ils choisissent l'ordre d'exécution des tâches. Le Product Owner ordonne le Product Backlog, pas le Sprint Backlog.
Q10. Le Scrum Master modifie-t-il les backlogs ?
Réponse : jamais. Le Scrum Master coache, facilite, lève les impediments. Il n'est responsable d'aucun des deux backlogs. C'est l'erreur la plus fréquente au PSM I.
Anti-patterns observés en entreprise
Au-delà de la théorie, voici les dérives les plus fréquemment rencontrées dans les équipes Scrum francophones — toutes liées à une mauvaise compréhension de la distinction Sprint Backlog / Product Backlog.