Pourquoi des exemples concrets de Product Backlog ?
Comprendre la théorie du Product Backlog ne suffit pas à en construire un bon. Les Product Owners débutants, comme les candidats au PSM I, butent presque toujours sur la même question : « à quoi ressemble concrètement un Product Backlog réel ? ». Cette page rassemble 8 exemples de Product Backlog détaillés, inspirés de produits réels, pour illustrer comment un PO traduit un Product Goal en items ordonnés, estimés et prêts à entrer en Sprint.
Chaque exemple suit la même structure : contexte, Product Goal, Product Backlog priorisé avec User Stories et autres Product Backlog Items, Story Points, valeur métier, critères d'acceptation, justification des priorités et enseignements à retenir. L'objectif n'est pas de fournir des templates à recopier — pour cela, consultez la page dédiée Product Backlog Template — mais bien de donner à voir ce qu'un Product Backlog mature contient réellement.
Du Product Goal à l'Increment
Tout exemple de Product Backlog s'inscrit dans le flux empirique de Scrum : un Product Goal définit l'horizon, un Product Backlog ordonné décline ce qui reste à faire, un Sprint Planning sélectionne le sous-ensemble livrable, et chaque Sprint produit un Increment conforme à la Definition of Done. Si vous confondez Product Backlog et Sprint Backlog, lisez d'abord Sprint Backlog vs Product Backlog.
Comment lire les exemples
- Prio : ordre de priorité (1 = sommet du backlog).
- SP : Story Points (échelle de Fibonacci).
- Valeur : impact métier attendu — €, taux de conversion, NPS, conformité.
- AC : critères d'acceptation principaux.
1. Application bancaire mobile
- Contexte
- Néobanque française, 850 000 clients, équipe Scrum de 6 Developers, Sprints de 2 semaines.
- Product Goal
- « Devenir l'application bancaire mobile la mieux notée du marché français d'ici 12 mois (note ≥ 4,7/5, NPS ≥ 60). »
| # | Titre / User Story | Prio | SP | Valeur | Critères d'acceptation |
|---|---|---|---|---|---|
| PB-101 | Authentification biométrique (Face ID / empreinte) En tant que client, je veux me connecter sans saisir mon mot de passe, afin d'accéder rapidement à mes comptes. | 1 | 8 | +18 % satisfaction onboarding | Face ID + empreinte ; fallback PIN ; échec → biométrie après 3 tentatives. |
| PB-102 | Notification temps réel des transactions En tant que client, je veux être notifié immédiatement de chaque opération carte, pour détecter une fraude. | 2 | 13 | −35 % fraudes non détectées | < 2 s après autorisation ; push + in-app ; opt-in RGPD. |
| PB-103 | Virement instantané SEPA En tant que client, je veux envoyer un virement reçu en < 10 s par le bénéficiaire. | 3 | 21 | +22 % rétention | Conforme SCT Inst ; limite 1 000 € ; SCA forte. |
| PB-104 | Plafonds carte modifiables en self-service En tant que client, je veux ajuster mes plafonds depuis l'app, sans contacter le support. | 4 | 5 | −2 200 tickets/mois | Plafond hebdo / mensuel ; SCA ; effet immédiat. |
| PB-105 | Catégorisation automatique des dépenses En tant que client, je veux voir mes dépenses regroupées par catégorie. | 5 | 13 | +11 % NPS | 12 catégories ; ML > 85 % précision ; édition manuelle. |
| PB-106 | Bug : crash sur Android 12 (login) | 6 | 3 | Stabilité critique | Crash-free rate > 99,7 % ; tests sur 5 devices. |
| PB-107 | Dette technique : refactor module paiement | 7 | 8 | Vélocité +20 % | Couverture tests > 80 % ; CI verte ; rollback OK. |
| PB-108 | Coffre-fort de documents | 8 | 21 | Différenciation marché | Upload chiffré ; OCR ; partage temporaire. |
2. Site e-commerce
- Contexte
- Pure player mode, 1,2 M visiteurs/mois, taux de conversion 1,8 %, panier moyen 78 €.
- Product Goal
- « Passer de 1,8 % à 2,6 % de taux de conversion en 2 trimestres. »
| # | Titre / User Story | Prio | SP | Valeur | Critères d'acceptation |
|---|---|---|---|---|---|
| EC-201 | Checkout invité (sans création de compte) En tant que visiteur, je veux acheter sans créer de compte, pour gagner du temps. | 1 | 13 | +0,4 pt conversion estimés | E-mail + adresse ; paiement Stripe ; compte créé a posteriori en 1 clic. |
| EC-202 | Apple Pay & Google Pay | 2 | 8 | +0,2 pt conversion mobile | Disponibles dès la page panier ; fallback CB. |
| EC-203 | Page produit : photos zoomables HD + vidéo | 3 | 8 | −9 % retours | Zoom ×4 ; vidéo < 6 Mo ; lazy-load ; A/B test. |
| EC-204 | Recommandations « clients ayant acheté » | 4 | 13 | +3 % AOV | Algo collaboratif ; refresh quotidien ; fallback best-sellers. |
| EC-205 | Filtres avancés (couleur, taille, prix, marque) | 5 | 8 | +0,1 pt conversion | Multi-sélection ; URL partageable ; SEO friendly. |
| EC-206 | Programme de fidélité (points) | 6 | 21 | +5 % rétention | 1 € = 1 pt ; expiration 12 mois ; barre de progression. |
| EC-207 | Refonte fiche produit accessibilité WCAG AA | 7 | 13 | Conformité + SEO | Audit Lighthouse > 95 ; contraste AA ; navigation clavier. |
| EC-208 | Spike : faisabilité recherche vectorielle | 8 | 5 | Apprentissage | POC sur 10 000 produits ; rapport en Sprint Review. |
3. Application mobile de fitness
- Contexte
- Application iOS/Android, 320 000 MAU, freemium, équipe Scrum de 5 Developers.
- Product Goal
- « Atteindre 50 000 abonnés Premium dans 9 mois (conversion freemium → paid). »
| # | Titre / User Story | Prio | SP | Valeur | Critères d'acceptation |
|---|---|---|---|---|---|
| FT-301 | Programmes d'entraînement personnalisés (IA) | 1 | 21 | Pilier Premium | Algo basé sur niveau, objectif, équipement ; 4 séances/semaine générées. |
| FT-302 | Synchronisation Apple Health & Google Fit | 2 | 13 | Rétention J30 +12 % | Lecture + écriture ; permissions claires ; bidirectionnel. |
| FT-303 | Paywall optimisé après 3e séance | 3 | 5 | +0,8 pt conversion | A/B test 3 variantes ; tracking funnel ; restore purchase. |
| FT-304 | Mode hors-ligne pour les séances téléchargées | 4 | 8 | NPS +6 pts | Téléchargement audio + vidéo ; gestion espace disque. |
| FT-305 | Tableau de bord progression hebdo | 5 | 8 | Engagement +9 % | Calories, séances, durée, records personnels ; partage social opt-in. |
| FT-306 | Bug : sons coupés sur AirPods Pro 2 | 6 | 3 | Bloquant utilisateur premium | Reproduit, corrigé, testé sur iOS 17 + 18. |
4. SaaS B2B — CRM commercial
- Contexte
- CRM SaaS, 1 200 clients PME, ARR 8 M€, contrats annuels, churn 14 %.
- Product Goal
- « Réduire le churn annuel de 14 % à 8 % en 12 mois. »
| # | Titre / User Story | Prio | SP | Valeur | Critères d'acceptation |
|---|---|---|---|---|---|
| CRM-401 | Onboarding guidé en 7 étapes | 1 | 13 | −4 pts churn J90 | Tour produit ; tooltips contextuels ; opt-out ; mesure complétion. |
| CRM-402 | Imports CSV/Excel intelligents (mapping IA) | 2 | 21 | −65 % tickets support | Détection auto colonnes ; preview ; rollback ; logs RGPD. |
| CRM-403 | Intégration native Outlook & Gmail | 3 | 21 | Engagement +30 % | OAuth ; sync bidirectionnelle ; opt-in par contact. |
| CRM-404 | Tableau de bord NPS client par compte | 4 | 8 | Action proactive CSM | Score / segment / tendance 30j ; export PDF. |
| CRM-405 | Conformité SOC 2 Type II | 5 | 21 | Déverrouille deals Enterprise | Audit externe passé ; logs ; SSO SAML. |
| CRM-406 | API publique v2 + documentation OpenAPI | 6 | 13 | Écosystème partenaires | Rate limiting ; versioning ; sandbox ; doc Redoc. |
| CRM-407 | Dette : migration PostgreSQL 12 → 16 | 7 | 13 | Performance +35 % | Zero downtime ; rollback testé ; observabilité. |
5. Logiciel RH
- Contexte
- SIRH cloud, 480 entreprises clientes, gestion congés / paie / entretiens.
- Product Goal
- « Devenir la référence française pour les PME de 50 à 500 salariés sur la gestion des entretiens annuels. »
| # | Titre / User Story | Prio | SP | Valeur | Critères d'acceptation |
|---|---|---|---|---|---|
| HR-501 | Trames d'entretien annuel personnalisables | 1 | 13 | Différenciation marché | Builder drag-and-drop ; 6 questions types ; export DOCX. |
| HR-502 | Workflow validation manager → RH → DG | 2 | 21 | Adoption RH +40 % | Notifications ; relances auto ; piste d'audit. |
| HR-503 | Signature électronique eIDAS | 3 | 13 | Conformité légale | Niveau avancé ; horodatage ; archivage 10 ans. |
| HR-504 | Tableau de bord RH (taux complétion) | 4 | 8 | Pilotage | Par service ; export Excel ; filtres période. |
| HR-505 | App mobile salarié (consultation + signature) | 5 | 21 | Couverture mobile | iOS + Android ; offline read ; biométrie. |
| HR-506 | Connecteur SSO (Azure AD, Google Workspace) | 6 | 8 | Enterprise ready | SAML 2.0 ; provisioning SCIM ; logs. |
6. Plateforme de streaming
- Contexte
- Service SVOD européen, 4 M abonnés, catalogue 6 800 titres, équipe produit multi-team.
- Product Goal
- « Réduire le churn mensuel de 4,2 % à 2,8 % en 12 mois grâce à une découverte de contenu radicalement améliorée. »
| # | Titre / User Story | Prio | SP | Valeur | Critères d'acceptation |
|---|---|---|---|---|---|
| ST-601 | Recommandations personnalisées (LLM-assisted) | 1 | 34 | Pilier rétention | Cold start résolu ; refresh quotidien ; explainability. |
| ST-602 | Reprise lecture multi-device temps réel | 2 | 13 | NPS +8 pts | Sync < 1 s ; supporte 4 devices simultanés. |
| ST-603 | Téléchargement hors-ligne 4K HDR | 3 | 21 | Différenciation iOS | DRM Widevine L1 ; expiration 30j ; gestion stockage. |
| ST-604 | Sous-titres communautaires (FR ↔ EN) | 4 | 13 | Couverture catalogue | Modération ; vote qualité ; backup officiel. |
| ST-605 | Profil enfant (contrôle parental renforcé) | 5 | 8 | Conformité + acquisition | Code PIN ; restrictions ; reporting parental. |
| ST-606 | Bug : lecture HDR cassée sur Apple TV tvOS 17 | 6 | 5 | Segment premium | Régression corrigée ; tests automatisés ajoutés. |
7. Application de santé connectée
- Contexte
- Application iOS/Android certifiée DM Classe IIa, suivi glycémie diabète type 2.
- Product Goal
- « Améliorer l'équilibre glycémique (HbA1c) de 0,5 point chez 70 % des utilisateurs réguliers en 6 mois. »
| # | Titre / User Story | Prio | SP | Valeur | Critères d'acceptation |
|---|---|---|---|---|---|
| HE-701 | Connectivité lecteurs glycémie Bluetooth (top 5 marques) | 1 | 21 | Pilier produit | BLE 5.0 ; pairing < 30 s ; gestion 5 marques majeures. |
| HE-702 | Alertes intelligentes hypo/hyperglycémie | 2 | 13 | Sécurité patient | Seuils personnalisés ; SMS contact urgence ; logs MDR. |
| HE-703 | Conformité MDR + ISO 13485 (mise à jour DM) | 3 | 21 | Mise sur marché EU | Documentation technique ; audit organisme notifié OK. |
| HE-704 | Export PDF rapport médecin | 4 | 8 | Adoption professionnels | Périodes paramétrables ; graphiques AGP ; envoi sécurisé. |
| HE-705 | Coaching nutritionnel basé sur scan code-barres | 5 | 13 | Engagement +20 % | Base OpenFoodFacts ; suggestions IA ; opt-in. |
8. Plateforme d'IA générative
- Contexte
- SaaS d'IA générative B2B, 4 500 utilisateurs, génération de contenus marketing multilingues.
- Product Goal
- « Devenir le standard de génération de contenu marketing pour les équipes marketing européennes de 10 à 100 personnes. »
| # | Titre / User Story | Prio | SP | Valeur | Critères d'acceptation |
|---|---|---|---|---|---|
| AI-801 | Brand voice : fine-tuning par client | 1 | 34 | Différenciation forte | Upload 20 docs ; modèle isolé ; A/B avec base. |
| AI-802 | Détection & masquage automatique de PII | 2 | 13 | Conformité RGPD | Précision > 98 % ; logs ; opt-in par projet. |
| AI-803 | Multi-LLM routing (coût/qualité/latence) | 3 | 21 | Marge brute +12 pts | GPT-4o, Claude, Mistral ; règles configurables ; observabilité. |
| AI-804 | Workflow d'approbation éditoriale | 4 | 13 | Adoption entreprise | Rôles éditeur/relecteur/manager ; commentaires ; historique. |
| AI-805 | Évaluation qualité (rating humain + auto) | 5 | 13 | Boucle d'amélioration | Échelle 1-5 ; capture rationale ; dashboard tendances. |
| AI-806 | Conformité AI Act EU (transparence) | 6 | 21 | Conformité 2026 | Étiquetage contenus générés ; registre ; doc système. |
Évolution du Product Backlog au fil des Sprints
Un Product Backlog n'est jamais figé. Il se transforme à chaque Sprint, sous l'effet de trois forces : l'apprentissage (feedbacks Sprint Review, métriques d'usage), la priorisation (arbitrages stratégiques du PO), et le refinement continu (~10 % de la capacité). Voici la dynamique typique observée sur les 5 premiers Sprints d'un produit.
Le Product Backlog Refinement est l'activité continue qui assure cette transformation. Les items au sommet sont fins, prêts, estimés ; les items du bas restent volontairement grossiers. C'est le principe DEEP : Detailed appropriately, Estimated, Emergent, Prioritized.
Pourquoi ces exemples fonctionnent
- Un Product Goal ancrant chaque item. Chaque PBI peut être justifié par sa contribution au Product Goal.
- Une priorisation explicite et défendable. Le PO peut expliquer en une phrase pourquoi PB-101 passe avant PB-108.
- Une valeur métier quantifiée. €, %, NPS, conformité : tout est mesurable.
- Des critères d'acceptation testables. Pas d'AC vague type « doit être ergonomique ».
- Un mélange sain de features, bugs, dette technique, conformité et spikes.
- Une granularité décroissante du haut vers le bas (DEEP).
Erreurs fréquentes observées dans les Product Backlogs
- Backlog vide en bas, surchargé en haut. 200 items prêts, aucune vision long terme.
- Tous les items au même niveau de priorité. « Must have » partout = aucune priorité réelle.
- Aucun critère d'acceptation. Les Developers découvrent les attentes en Sprint Planning.
- Bugs et dette traités hors backlog. Listes parallèles → conflits de priorisation.
- PO absent. Le Scrum Master ou un Developer arbitre — anti-pattern majeur PSM I.
- Items techniques cachés. La dette s'accumule, la vélocité chute, les stakeholders ne comprennent pas.
- Estimation imposée par le management. Les Story Points appartiennent aux Developers (Scrum Guide).
- Refinement traité comme un événement. Aucun temps dédié → backlog illisible.
Comment améliorer un mauvais Product Backlog en 5 Sprints
- Sprint 1 — Reformuler le Product Goal. Une phrase. Mesurable. Engageante. Validée avec les stakeholders.
- Sprint 2 — Nettoyer. Supprimer ou archiver tout item de plus de 6 mois sans réactivation. 20 à 40 % du backlog disparaît typiquement.
- Sprint 3 — Re-prioriser explicitement. Top 30 items uniquement, ordonnés un à un, sans ex æquo.
- Sprint 4 — Ajouter AC, SP, valeur. Sur les 15 premiers items. Pas plus : DEEP impose granularité décroissante.
- Sprint 5 — Instaurer un refinement régulier. 2 sessions × 1 h par semaine. Mesurer le ratio « ready » avant Sprint Planning.