Le Product Backlog Refinement est l'activité la plus sous-estimée de Scrum. Elle n'apparaît dans aucun des cinq événements officiels du Scrum Guide 2020 — et pourtant, sans elle, le Sprint Planning devient ingérable et le Product Backlog s'effondre. Ce guide est conçu pour devenir la meilleure ressource francophone sur le refinement, ses objectifs, ses participants, ses pièges et les questions PSM I qui s'y rapportent.
Définition du Product Backlog Refinement
Le Scrum Guide 2020 énonce : « Le Product Backlog refinement est l'action consistant à décomposer et à définir plus précisément les Product Backlog Items en items plus petits et plus précis. C'est une activité continue qui consiste à ajouter des détails, comme une description, l'ordre et la taille. » Les attributs varient souvent en fonction du domaine de travail.
Trois mots-clés sont essentiels dans cette définition :
- « Activité continue » — le refinement n'est pas un événement ponctuel, c'est un flux régulier.
- « Décomposer » — les gros items sont découpés en items plus petits, livrables en un Sprint.
- « Ajouter des détails » — description, critères d'acceptation, ordre, taille.
Product Backlog Refinement vs Backlog Grooming
Vous croiserez encore le terme Backlog Grooming, notamment dans la documentation pré-2011 et dans certaines équipes francophones par habitude. C'est l'ancien terme, et il a été délibérément retiré du vocabulaire Scrum officiel.
| Critère | Backlog Grooming (ancien) | Backlog Refinement (actuel) |
|---|---|---|
| Période d'usage | Avant 2011 | Depuis 2011, officialisé en 2017 |
| Statut Scrum Guide | Jamais formalisé | Présenté comme activité continue |
| Connotation EN | Ambiguë (« grooming » a pris une connotation négative en anglais) | Neutre, descriptive |
| Usage recommandé | À éviter, surtout à l'écrit ou à l'examen PSM I | Terme officiel à utiliser systématiquement |
| Équivalent français | « Toilettage » (rarement utilisé) | « Affinage » ou « raffinement » |
Objectifs du Product Backlog Refinement
Le refinement poursuit six objectifs simultanés. Chaque session n'a pas besoin de tous les couvrir — l'important est que le haut du Product Backlog progresse régulièrement vers un état exploitable.
1. Clarifier les Product Backlog Items
Chaque PBI doit être compris sans ambiguïté par les Developers et le PO. La clarification passe par des questions, des exemples, des maquettes ou un échange avec un expert métier invité ponctuellement.
2. Découper les items trop gros
Un PBI qui ne tient pas dans un Sprint doit être découpé en items plus petits. C'est l'application directe du « S » du critère INVEST (Small). Sans découpage, le Sprint Planning produira soit un Sprint Goal trop ambitieux, soit un Sprint Backlog inestimable.
3. Ajouter ou préciser les critères d'acceptation
Les critères d'acceptation rendent un PBI testable. Ils ne sont pas une Definition of Done (qui s'applique à tout l'Increment), mais des conditions spécifiques au PBI : « le paiement échoue si le solde est insuffisant », « l'email est envoyé en moins de 10 secondes », etc.
4. Estimer si nécessaire
Les Developers — et eux seuls — estiment le travail. Story Points, T-shirt sizes, idéal-days : le Scrum Guide ne prescrit aucune technique. L'estimation aide la prévisibilité et soutient l'ordonnancement par le PO.
5. Supprimer les items obsolètes
Le Product Backlog est vivant. Une partie du refinement consiste à enlever les items qui ne servent plus le Product Goal : fonctionnalités abandonnées, bugs résolus autrement, requêtes périmées. Un Backlog propre est un Backlog utilisable.
6. Ordonner le Product Backlog
Le Product Owner est responsable de l'ordre. Le refinement est un excellent moment pour réviser cet ordre à la lumière des nouvelles informations : dépendances découvertes, feedback de Sprint Review, contraintes techniques remontées par les Developers.
Qui participe au Product Backlog Refinement ?
Le refinement est une activité du Scrum Team. Les rôles attendus sont :
| Rôle | Participation | Responsabilité |
|---|---|---|
| Product Owner | Obligatoire de fait | Apporte la vision produit, le Product Goal, les priorités business et les arbitrages de valeur. |
| Developers | Obligatoire | Posent les questions techniques, estiment, découpent, identifient les dépendances et la faisabilité. |
| Scrum Master | Optionnel — facilite si utile | Sert l'efficacité du Scrum Team. Coache l'équipe pour rendre le refinement plus efficace. |
| Stakeholders | Invités ponctuels | Apportent expertise métier, contrainte légale ou clarification d'un besoin spécifique. Ne pilotent jamais. |
| Architectes / Tech leads externes | Invités ponctuels | Clarifient une contrainte d'infrastructure ou d'intégration. Pas de présence permanente. |
Quand faire du refinement ?
Le refinement est une activité continue. Cela signifie plusieurs choses concrètes :
- Pas forcément une réunion unique. Beaucoup d'équipes alternent sessions formelles (1 à 2 par semaine) et discussions courtes ad hoc.
- À tout moment du Sprint. Le refinement peut se faire dès que des PBI ont besoin d'être clarifiés ; il n'a pas à être confiné au milieu du Sprint.
- Pas le jour du Sprint Planning. Si vous découvrez les PBI au Planning, c'est trop tard — le Planning devient une session de refinement déguisée.
- Sur les items du haut de Backlog uniquement. Raffiner les items du bas est du gaspillage : leurs détails seront périmés avant qu'ils n'entrent en Sprint.
Combien de temps consacrer au refinement ?
Le Scrum Guide ne fixe aucune durée obligatoire. Une heuristique informelle, héritée des premières équipes Scrum, suggère d'y consacrer environ 10 % de la capacité du Sprint— soit, pour un Sprint de deux semaines, environ une demi-journée par Developer. Mais ce chiffre n'est pas une règle Scrum officielle.
| Contexte | Temps recommandé | Pourquoi |
|---|---|---|
| Équipe Scrum débutante | 10–15 % de la capacité Sprint | Besoin d'apprendre à découper et estimer ensemble. |
| Équipe mature, domaine stable | 5–8 % de la capacité Sprint | Conventions acquises, PBI souvent autoporteurs. |
| Produit très complexe ou réglementé | 12–15 % | Critères d'acceptation lourds, dépendances multiples. |
| Nouveau produit / Discovery active | 15 % et plus | Beaucoup de découpage, exploration, hypothèses à valider. |
| Produit en maintenance | 3–5 % | Backlog stable, principalement des bugs et petites améliorations. |
Product Backlog Refinement vs Sprint Planning
C'est la confusion la plus fréquente au PSM I — et sur le terrain. Le tableau qui suit fait la différence sur huit dimensions.
| Critère | Product Backlog Refinement | Sprint Planning |
|---|---|---|
| Statut Scrum | Activité continue (non listée comme événement) | Événement officiel du Scrum Guide |
| Objectif | Préparer les futurs PBI : clarifier, découper, estimer | Produire un Sprint Goal et un Sprint Backlog |
| Moment | À tout moment du Sprint, en continu | Au démarrage de chaque Sprint |
| Time-box | Aucune (recommandation informelle ~10 %) | Max 8 h pour un Sprint d'1 mois (proportionnel) |
| Participants | PO + Developers (+ SM si utile, stakeholders ponctuels) | Tout le Scrum Team obligatoirement |
| Livrable | PBI Ready, Backlog ordonné | Sprint Goal + Sprint Backlog + plan du « Why / What / How » |
| Niveau d'engagement | Aucun engagement de livraison | Engagement explicite de la Scrum Team sur le Sprint Goal |
| Lien avec Sprint Goal | Aide indirectement (en préparant des PBI cohérents) | Définit le Sprint Goal de ce Sprint |
| Erreur fréquente | Devenir un mini Sprint Planning anticipé | Servir de session de refinement (= Planning à rallonge) |
Exemple concret de session de refinement
Pour rendre le refinement tangible, voici une session complète sur un produit fictif : Passe Ton Scrum, plateforme d'entraînement aux certifications PSM I. L'équipe Scrum est composée d'un PO, de 4 Developers et d'un Scrum Master. Sprint actuel : Sprint 14. Sprint de deux semaines.
Contexte avant la session
À J+8 du Sprint 14, le PO planifie une session de refinement d'1h30. Le haut du Product Backlog contient cinq PBI flous, écrits rapidement par le PO après un échange utilisateur.
| # | Titre brut | Problèmes identifiés |
|---|---|---|
| PBI-101 | Améliorer le quiz | Trop vague, aucun critère, taille inconnue. |
| PBI-102 | Mode examen blanc complet | Très gros, probablement plusieurs Sprints. À découper. |
| PBI-103 | Stats utilisateur | Quels indicateurs ? Quel format ? Aucune AC. |
| PBI-104 | Tag « difficulté » sur les questions | Petit mais critères d'acceptation absents. |
| PBI-105 | Refonte du Login | Pas de Product Goal lié. À challenger. |
Déroulé de la session (1 h 30)
- 00:00 — Cadrage (5 min). Le SM rappelle l'objectif : rendre Ready 2 à 3 PBI pour le prochain Sprint Planning.
- 00:05 — PBI-101 (15 min). Les Developers posent des questions. Le PO clarifie : « améliorer le quiz » = afficher l'explication détaillée après chaque réponse. Découpé en deux PBI : affichage de l'explication + ajout de schémas par question.
- 00:20 — PBI-102 (25 min). Trop gros. Découpé en 4 PBI : mode 80 Q chronométré, écran récap, persistance des résultats, certificat PDF. Estimations rapides en Story Points.
- 00:45 — PBI-103 (15 min). Les Developers proposent 3 indicateurs MVP. Le PO valide. AC définis. Estimé.
- 01:00 — PBI-104 (10 min). AC ajoutés en 5 minutes. Estimé.
- 01:10 — PBI-105 (15 min). Aucune valeur clairement liée au Product Goal courant. Le PO accepte de le sortir du haut de Backlog et de le reprioriser plus tard.
- 01:25 — Clôture (5 min). Le SM résume : 6 PBI Ready, 1 PBI démoté, prochaine session dans 5 jours.
Résultat — état APRÈS refinement
| # | Titre raffiné | AC clés | Estimation |
|---|---|---|---|
| PBI-101a | Afficher l'explication détaillée après chaque réponse | Texte ≤ 200 mots ; affiché immédiatement ; toujours accessible. | 3 SP |
| PBI-101b | Permettre d'ajouter un schéma SVG par question | Upload, prévisualisation, alt obligatoire. | 5 SP |
| PBI-102a | Mode 80 Q chronométré (1 h) | Timer visible, soumission auto. | 5 SP |
| PBI-102b | Écran récap fin d'examen | Score, temps, % par catégorie. | 3 SP |
| PBI-102c | Persistance des résultats utilisateur | Stockage chiffré, 12 mois. | 5 SP |
| PBI-103 | Stats utilisateur MVP (3 indicateurs) | Score moyen, taux de réussite par thème, courbe progression. | 5 SP |
| PBI-104 | Tag difficulté sur chaque question | Niveaux facile/moyen/difficile, filtres. | 2 SP |
Checklist Product Backlog Refinement
Une checklist opérationnelle pour structurer vos sessions — applicable à toute Scrum Team, débutante ou mature.
Avant la session
- Le Product Owner a identifié les PBI candidats (haut du Backlog).
- Chaque PBI candidat a au moins un titre, un contexte et un objectif business.
- Les Developers ont parcouru les PBI 24 h à l'avance pour préparer leurs questions.
- Les stakeholders éventuellement utiles ont été identifiés et conviés ponctuellement.
- La capacité allouée est connue (souvent 60 à 90 min par session).
Pendant la session
- Un PBI à la fois, time-box courte par PBI (10–20 min).
- Questions de clarification posées librement par les Developers.
- Découpage des PBI trop gros — viser des items livrables en 1 Sprint.
- Ajout ou affinage des critères d'acceptation.
- Estimation par les Developers (Story Points, T-shirt, etc.).
- Identification des dépendances internes ou externes.
- Décision claire par PBI : Ready / À retravailler / Démoté / Supprimé.
- Aucun engagement de livraison n'est pris.
Après la session
- Le Product Backlog est mis à jour dans l'outil (Jira, Azure DevOps, etc.).
- Le PO réordonne si nécessaire à la lumière des nouvelles informations.
- Les PBI Ready sont visiblement marqués comme tels.
- Les questions ouvertes sont notées comme actions assignées.
- La prochaine session de refinement est planifiée.
Signes d'un bon refinement
Comment savoir si votre refinement fonctionne ? Vérifiez ces sept indicateurs observables.
| Signe | Pourquoi c'est important | Symptôme inverse |
|---|---|---|
| Les PBI Ready sont compris à l'identique par tous les Developers | Compréhension partagée = base de l'estimation et du Sprint Goal | Au Sprint Planning, chaque Developer interprète le PBI différemment |
| Les items du haut de Backlog tiennent dans un Sprint | Découpage suffisant pour engager un Sprint Goal réaliste | Sprint Goal régulièrement raté faute de PBI trop gros |
| Les dépendances sont visibles avant le Sprint | Évite les blocages en plein Sprint | Découverte d'une dépendance critique à J+3 du Sprint |
| Les critères d'acceptation sont clairs et testables | Permet à l'équipe de savoir quand un PBI est Done | Discussions interminables sur « est-ce que c'est terminé ? » en Sprint Review |
| Toute l'équipe peut expliquer le Product Goal | Aligne le refinement et les arbitrages | Les Developers refinent des PBI sans saisir leur lien avec la vision produit |
| Le Sprint Planning suivant est fluide (≤ 2 h pour un Sprint de 2 semaines) | Preuve que les PBI sont vraiment prêts | Sprint Planning qui s'éternise à clarifier les PBI |
| Aucun PBI Ready ne reste plus de 2 Sprints sans entrer en Sprint | Évite le gaspillage de refinement | PBI raffinés en avril, oubliés et obsolètes en juin |
15 anti-patterns à éviter
- Transformer le refinement en Sprint Planning anticipé. Décider qui fait quoi pour le Sprint suivant trahit la finalité du refinement et grille les options.
- Product Owner qui impose tout. Le PO décide du « quoi » et de l'ordre, jamais du « comment ». Imposer le découpage technique tue l'auto-gestion.
- Developers absents ou silencieux. Un refinement sans questions techniques est un refinement raté. Le PO repart avec des PBI flous.
- Estimation mécanique pour aller vite. Estimer sans avoir compris le PBI produit des chiffres faux qui contamineront la planification.
- Critères d'acceptation oubliés. Sans AC testables, le PBI n'est pas Ready — il déclenchera des débats interminables en Sprint Review.
- Refinement uniquement juste avant le Sprint Planning. Conduit à un Planning à rallonge et à des PBI mal pensés.
- Backlog rempli de tickets techniques incompréhensibles. Les PBI doivent porter de la valeur métier compréhensible par le PO et les stakeholders.
- Stakeholders qui pilotent directement la session. Les stakeholders sont invités, pas décideurs. Le PO reste le seul accountable.
- Confusion entre « Ready » et « Done ». Ready = prêt à entrer en Sprint. Done = livré et conforme à la DoD. Ce sont deux états distincts.
- Definition of Ready utilisée comme gate contractuel rigide. La DoR est un guide d'équipe, pas un contrat opposable au PO ou aux stakeholders.
- Raffiner les items du bas de Backlog. Pure perte : leurs détails seront périmés. Concentrez-vous sur les 1 à 2 prochains Sprints.
- Sessions de 3 heures « pour tout traiter d'un coup ». Au-delà de 90 min, la qualité chute. Plusieurs sessions courtes valent mieux.
- Scrum Master qui dirige. Le SM facilite, pas plus. Le PO et les Devs portent le contenu.
- Aucune trace écrite après la session. Sans mise à jour de l'outil, le refinement est perdu et devra être refait.
- Refinement comptabilisé dans la vélocité. Le refinement est une activité, pas un PBI livré. L'inclure fausse la mesure.
Product Backlog Refinement et PSM I
Le refinement génère un cluster de questions parfois piégeuses à l'examen PSM I. Voici les pièges les plus fréquents et la posture à adopter.
| Affirmation | Vraie ou fausse ? | Pourquoi |
|---|---|---|
| Le refinement est un événement Scrum | Faux | Le Scrum Guide liste 5 événements ; refinement n'en fait pas partie. |
| Le refinement a une time-box officielle | Faux | Aucune durée n'est imposée par le Scrum Guide. |
| Le PO peut faire le refinement seul | Partiellement vrai | Il prépare seul, mais sans les Devs le refinement n'est pas complet. |
| Le Scrum Master doit assister à tout refinement | Faux | Il facilite si utile, mais sa présence n'est pas requise. |
| La Definition of Ready est un artefact Scrum | Faux | Non listée dans le Scrum Guide. Convention d'équipe utile mais facultative. |
| Le refinement engage l'équipe sur la livraison | Faux | L'engagement vient au Sprint Planning, sur le Sprint Goal. |
| Refinement ≈ 10 % de la capacité Sprint | Faux (au sens officiel) | Heuristique de communauté, pas une règle Scrum. |
| Les bugs peuvent être refinés | Vrai | Tout ce qui est dans le Product Backlog est éligible au refinement. |
10 questions PSM I corrigées sur le refinement
Ressources et maillage interne
Le refinement s'inscrit dans le cluster Backlog Produit. Pour en tirer toute la valeur, parcourez les exemples sectoriels de Product Backlog, les templates Excel, Jira et Notion, et notre comparatif Sprint Backlog vs Product Backlog ci-dessous.
Source officielle : Scrum Guide 2020.