Votre équipe StockPro est en place : Awa au produit, Karim au cadre, et trois Developers prêts à coder. La première question qui tue : « on commence par quoi ? » Si la réponse vit dans la tête d’Awa, dans un fichier tableur oublié et dans trois conversations contradictoires, l’équipe va construire au hasard. Le Product Backlog est l’outil qui transforme « tout ce qu’on aimerait faire » en une liste ordonnée, unique et visible de ce qui crée vraiment de la valeur. À la fin de ce tutoriel, vous saurez rédiger des éléments de backlog clairs, les rattacher à un objectif produit, et les ordonner pour que l’équipe sache toujours quoi prendre ensuite.
Ce que vous allez apprendre
- Ce qu’est le Product Backlog et son engagement, le Product Goal, selon le Guide Scrum 2020.
- Rédiger un élément de backlog actionnable, au format user story, avec des critères d’acceptation.
- Appliquer la grille INVEST pour reconnaître un bon élément d’un mauvais.
- Ordonner le backlog et l’affiner (refinement) pour qu’il reste prêt à l’emploi.
Ce que vous allez construire
Vous repartirez avec le Product Backlog initial de StockPro : un objectif produit clair, une dizaine d’éléments rédigés proprement, ordonnés du plus précieux au moins urgent, et les trois ou quatre éléments du haut suffisamment détaillés pour entrer dans un Sprint. C’est le document de travail qui guidera tous les Sprints suivants.
Prérequis
- Avoir constitué l’équipe et désigné le Product Owner — voir Constituer une équipe Scrum.
- Un outil pour héberger la liste : un tableau partagé suffit pour démarrer ; un outil dédié viendra plus tard.
- Niveau : débutant. Durée estimée : 35 à 45 minutes pour un premier backlog.
Étape 1 — Comprendre le Product Backlog et le Product Goal
Le Guide Scrum 2020 définit le Product Backlog comme une liste émergente et ordonnée de ce qui est nécessaire pour améliorer le produit. C’est la source unique de travail de l’équipe Scrum : rien n’est construit qui ne vienne du backlog. « Émergente » est un mot important : le backlog n’est jamais figé ni complet, il évolue à mesure qu’on apprend du produit et des utilisateurs.
À ce backlog est attaché un engagement (commitment) : le Product Goal. Le Product Goal décrit un état futur du produit, un objectif à long terme vers lequel l’équipe avance. Le Product Backlog tout entier émerge pour définir « ce qui » permettra d’atteindre ce Product Goal. C’est la boussole. Pour StockPro, le Product Goal pourrait être : « permettre à la quincaillerie d’enregistrer ses ventes et de suivre son stock en temps réel, sans papier ». Tout élément du backlog doit, de près ou de loin, servir cet objectif.
✅ Point d’étape. Écrivez votre Product Goal en une phrase. Test : si un élément du backlog ne contribue à aucun moment à ce but, c’est sans doute qu’il n’a rien à y faire — ou que votre but est trop étroit.
Étape 2 — Rédiger un élément avec la user story
Le Guide Scrum ne dit pas comment écrire un élément de backlog : il laisse l’équipe libre du format. La user story est la convention la plus répandue — elle vient de la communauté Extreme Programming (format dit « Connextra », 2001) et a été popularisée par Mike Cohn. Ce n’est donc pas une règle Scrum officielle, mais une pratique complémentaire très utile. Sa force : elle place toujours l’utilisateur et son bénéfice au centre.
Le gabarit tient en trois parties : un rôle, un besoin, un bénéfice.
En tant que vendeur de la quincaillerie,
je veux enregistrer une vente en moins de 30 secondes,
afin de ne pas faire attendre le client au comptoir.Notez ce que cette formulation apporte : elle dit pour qui (le vendeur), quoi (enregistrer une vente vite) et surtout pourquoi (ne pas faire attendre le client). Le « pourquoi » est précieux : il permettra aux Developers de proposer une meilleure solution que celle imaginée au départ, parce qu’ils auront compris l’intention.
Une user story sans critères d’acceptation reste floue. Ajoutez-les sous forme de conditions vérifiables :
Criteres d'acceptation :
- La vente enregistre au moins un article, une quantite et un prix.
- Le stock de l'article diminue automatiquement apres validation.
- Un recapitulatif s'affiche avant validation definitive.Ces critères ne sont pas la Definition of Done (qui, elle, s’applique à tout l’incrément) : ce sont les conditions spécifiques qui disent « cette story-là est satisfaite ».
Étape 3 — Filtrer avec la grille INVEST
Comment savoir si un élément est bien écrit ? La grille INVEST, proposée par Bill Wake en 2003, donne six critères. C’est, là encore, une pratique complémentaire, pas une exigence du Guide Scrum — mais elle évite des heures de mauvaise surprise. Chaque lettre est un test :
| Lettre | Critère | Question à se poser |
|---|---|---|
| I | Independent (indépendant) | Peut-on la livrer sans dépendre d’une autre story ? |
| N | Negotiable (négociable) | Est-ce une intention discutable, pas un cahier des charges figé ? |
| V | Valuable (de valeur) | Apporte-t-elle un bénéfice visible à un utilisateur ? |
| E | Estimable | L’équipe peut-elle estimer son effort ? |
| S | Small (petite) | Tient-elle dans un Sprint, idéalement bien moins ? |
| T | Testable | Saura-t-on prouver qu’elle est faite ? |
Reprenons notre story « enregistrer une vente ». Est-elle indépendante ? Presque : elle suppose qu’on puisse choisir un article, donc qu’une liste d’articles existe. Si ce n’est pas le cas, on a découvert une story préalable. Est-elle petite ? Si « enregistrer une vente » englobe aussi les retours, les remises et le paiement mobile, non : il faut la découper. INVEST sert exactement à cela — révéler les éléments trop gros ou mal posés avant de s’engager dessus.
✅ Point d’étape. Passez vos cinq premières stories au filtre INVEST. Toute story qui échoue sur « Small » ou « Testable » doit être redécoupée ou reformulée maintenant.
Étape 4 — Ordonner le backlog
Un backlog n’est pas une liste de courses où l’ordre est indifférent. Le Guide Scrum confie au Product Owner la responsabilité d’ordonner les éléments. L’ordre encode une décision : ce qui est en haut sera construit en premier, parce que c’est ce qui crée le plus de valeur, réduit le plus de risque, ou débloque le reste.
Pour StockPro, Awa réfléchit ainsi : sans enregistrement de vente, l’application ne sert à rien ; cette story monte tout en haut. Le suivi du stock en découle directement ; il vient juste après. L’export comptable, lui, est utile mais peut attendre : il descend. L’ordre n’est pas gravé : à chaque nouvelle information, Awa réordonne. Un bon backlog se lit de haut en bas comme le plan de bataille du produit.
Évitez le piège du backlog « à plat » où tout est « prioritaire ». Si tout est prioritaire, rien ne l’est. Forcez un ordre strict : deux éléments ne peuvent pas occuper le même rang.
Étape 5 — Affiner le backlog (refinement)
Les éléments du haut doivent être prêts à entrer dans un Sprint ; ceux du bas peuvent rester de grosses idées vagues. Le passage de l’un à l’autre s’appelle l’affinage (Product Backlog refinement) dans le Guide Scrum : c’est l’activité continue qui consiste à découper et préciser les éléments en éléments plus petits et plus précis. Ce n’est pas un événement formel à durée fixe ; c’est un travail régulier, mené par l’équipe.
Point souvent mal compris : ce sont les Developers qui réalisent le travail qui sont responsables du dimensionnement (la taille) des éléments. Le Product Owner les aide à comprendre les arbitrages et à choisir, mais il n’impose pas une taille. Concrètement, l’équipe StockPro consacre par exemple une heure par semaine à regarder les prochains éléments : elle découpe « gérer les ventes » en stories digestes, clarifie les critères d’acceptation, et signale les zones d’ombre. Un élément suffisamment clair et petit pour être terminé dans un Sprint est considéré comme prêt à être sélectionné.
✅ Point d’étape final. Les trois ou quatre éléments du haut de votre backlog doivent être assez petits et clairs pour que l’équipe se dise « on saurait livrer ça dans un Sprint ». Si ce n’est pas le cas, continuez d’affiner avant le Sprint Planning.
Exemple : le backlog initial de StockPro
Pour fixer les idées, voici à quoi ressemble un premier Product Backlog ordonné pour StockPro après une séance d’affinage. Lisez-le de haut en bas comme l’ordre de construction décidé par Awa : chaque rang est unique, et la valeur décroît à mesure qu’on descend. Remarquez que les éléments du haut sont fins et prêts, tandis que ceux du bas restent volontairement grossiers — on les affinera quand ils approcheront.
| Rang | Élément | État |
|---|---|---|
| 1 | Enregistrer une vente simple (1 article, quantité, prix) | Prêt |
| 2 | Décrémenter automatiquement le stock après une vente | Prêt |
| 3 | Consulter le stock courant d’un article | Prêt |
| 4 | Ajouter plusieurs articles à une même vente | À affiner |
| 5 | Alerter quand un article passe sous un seuil | À affiner |
| 6 | Enregistrer un réapprovisionnement (entrée de stock) | À affiner |
| 7 | Gérer les retours et les remises | Idée |
| 8 | Exporter les ventes du mois pour le comptable | Idée |
Ce tableau n’est pas un contrat figé : c’est une photographie à un instant donné. Si la propriétaire signale demain que les ruptures de stock lui coûtent des clients, Awa fera remonter l’alerte de seuil (rang 5) au-dessus de l’ajout multi-articles (rang 4). Le backlog vit ; c’est sa nature même.
Pièges fréquents
| Symptôme | Cause probable | Correctif |
|---|---|---|
| L’équipe ne sait jamais quoi prendre | Backlog non ordonné, tout au même niveau | Forcer un ordre strict, un seul élément par rang |
| Les stories débordent toujours du Sprint | Éléments trop gros, jamais découpés | Affiner en continu, viser des stories petites (INVEST « S ») |
| On code la mauvaise chose | Story sans « afin de » (pas de pourquoi) | Toujours expliciter le bénéfice utilisateur |
| Impossible de dire si c’est fini | Pas de critères d’acceptation | Ajouter des conditions vérifiables à chaque story |
| Le Product Goal a disparu des écrans radar | Backlog déconnecté de l’objectif | Relier chaque élément au Product Goal, élaguer le reste |
Récapitulatif
Le Product Backlog est la source unique et ordonnée du travail de l’équipe, et son engagement est le Product Goal, l’objectif à long terme du produit. Vous savez désormais rédiger un élément au format user story — rôle, besoin, bénéfice — assorti de critères d’acceptation, puis le passer au crible INVEST pour repérer ce qui est trop gros ou trop flou. Le Product Owner ordonne le backlog du plus précieux au moins urgent, et l’équipe l’affine en continu pour garder le haut de la liste prêt à entrer en Sprint. StockPro a maintenant un plan de produit lisible, et non plus une pile d’idées éparses.
Aide-mémoire
| Élément | L’essentiel |
|---|---|
| Product Backlog | Liste émergente, ordonnée, source unique de travail (officiel Scrum) |
| Product Goal | Engagement du backlog : objectif produit à long terme (officiel Scrum) |
| User story | « En tant que… je veux… afin de… » (pratique complémentaire) |
| INVEST | Independent, Negotiable, Valuable, Estimable, Small, Testable (complémentaire) |
| Affinage | Découper et préciser en continu ; taille décidée par les Developers |
À vous de jouer
Awa écrit l’élément suivant : « Faire le module de gestion complète de la quincaillerie ». Que lui répondez-vous au regard d’INVEST ?
Voir une solution
Cet élément échoue sur plusieurs critères. Il n’est pas Small (il couvre tout le produit), ni Estimable (impossible à chiffrer en l’état), ni vraiment Testable (quand est-ce « fait » ?). Il faut le découper en stories concrètes : « enregistrer une vente », « voir le stock d’un article », « alerter quand un article passe sous un seuil », chacune avec son bénéfice et ses critères d’acceptation. On obtient ainsi des éléments qui passent INVEST et entrent dans un Sprint.
Tutoriels frères
- Estimer en équipe : story points et planning poker — chiffrer l’effort des éléments affinés.
- Préparer et animer le Sprint Planning — sélectionner les éléments du haut pour le prochain Sprint.
Ressources
- Vue d’ensemble : Scrum, le cadre Agile pour livrer un produit en équipe.
- Source de référence : le Guide Scrum 2020 (artefact Product Backlog et engagement Product Goal).
- Origine de la grille : Bill Wake, INVEST in Good Stories.
FAQ
La user story fait-elle partie de Scrum ?
Non, pas officiellement. Le Guide Scrum parle d’« éléments du Product Backlog » sans imposer de format. La user story est une convention complémentaire, très répandue parce qu’elle centre l’écriture sur l’utilisateur et son bénéfice.
Qui décide de la taille d’un élément ?
Les Developers qui feront le travail. Le Product Owner les aide à comprendre les arbitrages, mais il n’impose pas une estimation.
Faut-il que le backlog soit complet avant de commencer ?
Non. Il est émergent : on démarre avec assez d’éléments clairs en haut pour lancer un ou deux Sprints, puis il évolue à mesure qu’on apprend.
Quelle différence entre critères d’acceptation et Definition of Done ?
Les critères d’acceptation sont spécifiques à un élément (« cette story est satisfaite si… »). La Definition of Done est un standard de qualité commun à tout l’incrément, valable pour tous les éléments.