Définition officielle d'un Product Backlog Item
Un Product Backlog Item (PBI) est un élément du Product Backlog représentant quelque chose de nécessaire pour améliorer le produit. Le Scrum Guide 2020 n'impose aucun format unique : un PBI peut notamment représenter une fonctionnalité, une correction, un besoin technique, une expérimentation ou une exigence non fonctionnelle.
Le Product Owner est redevable de la création, de la communication claire et de l'ordonnancement des PBI ; les Developers qui réaliseront le travail sont responsables du dimensionnement. Les détails ajoutés au cours du refinement peuvent notamment inclure une description, un ordre et une taille ; les attributs varient selon le domaine de travail et Scrum n'impose aucune liste fixe de champs. Les PBI couvrent tout type de travail utile — User Story, bug, dette technique, spike, enabler ou exigence non fonctionnelle — et sont raffinés en continu par le Scrum Team.
Rôle des PBI dans le Product Backlog
Le Product Backlog n'a de sens que par les PBI qui le composent. Sans PBI clairs, ordonnés et raffinés, un Product Backlog devient une boîte noire incompréhensible pour les stakeholders et inutilisable par les Developers. Chaque PBI livré rapproche l'équipe du Product Goal via un Increment conforme à la Definition of Done.
Cycle de vie d'un PBI
Un PBI traverse plusieurs états entre son apparition et sa livraison :
- Idée — une hypothèse exprimée par un stakeholder, un utilisateur ou le PO.
- Backlog brut — l'item entre dans le Product Backlog, sans estimation fine.
- Raffiné — lors du Product Backlog Refinement, l'item gagne en clarté : description, AC, dépendances, Story Points.
- Ready — l'item satisfait la Definition of Ready éventuelle de l'équipe.
- Sprint — sélectionné lors du Sprint Planning, il rejoint le Sprint Backlog.
- Done — intégré à l'Increment livré et conforme à la Definition of Done.
Les différents types de Product Backlog Items
| Type | Description | Exemple | Estimation | Responsabilité |
|---|---|---|---|---|
| User Story | Besoin utilisateur exprimé en valeur métier. | « En tant que client, je veux activer Face ID… » | Story Points (Fibonacci) | PO rédige / Developers raffinent |
| Epic | Grande fonctionnalité qui se décompose en plusieurs User Stories. | « Onboarding client complet » | T-shirt (S, M, L, XL) | Product Owner |
| Bug | Écart entre comportement attendu et observé. | « Crash au login Android 12 » | Story Points ou temps | PO priorise / Devs corrigent |
| Dette technique | Travail technique différé qui freine la vélocité. | « Refactor module paiement » | Story Points | Developers proposent / PO arbitre |
| Spike | Recherche timeboxée pour lever une incertitude. | « POC recherche vectorielle, 3 jours » | Time-box (jours) | Developers |
| Enabler | Travail technique préalable qui rend possible une feature. | « Mettre en place le pipeline ML » | Story Points | Developers + Architecte |
| Non-fonctionnel | Performance, sécurité, accessibilité, conformité. | « P95 < 300 ms », « WCAG AA » | Story Points | Product Owner + Devs |
Note : les Story Points, la suite de Fibonacci, le T-shirt sizing et l'estimation en temps sont des pratiques d'estimation possibles ; Scrum n'impose aucune unité particulière.
Les formats présentés ci-dessous sont des pratiques largement utilisées dans l'industrie. Le Scrum Guide n'impose aucun format particulier pour les Product Backlog Items.
User Stories
La User Story est le format le plus répandu, popularisé par Mike Cohn. Elle est présentée ici comme un type possible de PBI ; pour un traitement approfondi, consultez le guide complet des User Stories. Structure classique :
« En tant que [rôle], je veux [action], afin de [valeur]. »
Exemple : « En tant que client mobile, je veux activer Face ID, afin de me connecter sans saisir mon mot de passe. » La User Story n'est pas un cahier des charges : c'est une promesse de conversation entre le PO et les Developers, souvent complétée par des critères d'acceptation.
Epics
Un Epic est un PBI trop volumineux pour tenir dans un seul Sprint. Il sera décomposé en plusieurs User Stories au fil du refinement. Le terme Epic n'apparaît pas dans le Scrum Guide ; c'est une commodité venue de XP et popularisée par Jira, Azure DevOps, SAFe.
Exemple : « Onboarding client complet » est un Epic qui se décompose en : inscription e-mail, vérification KYC, configuration profil, premier virement, tutoriel produit.
Bugs
Un bug est un écart entre le comportement attendu et le comportement observé d'une fonctionnalité existante. Le Scrum Guide est sans ambiguïté : les bugs vivent dans le Product Backlog et sont priorisés au même titre que les nouvelles features. Il n'existe pas de « backlog des bugs » séparé en Scrum.
Dette technique
La dette technique regroupe les compromis techniques différés : code dupliqué, framework obsolète, tests manquants, architecture inadaptée. C'est un PBI à part entière, dont la valeur s'exprime en vélocité future, fiabilité, capacité à recruter ou réduction d'incidents.
Spikes
Le terme « spike » est issu de pratiques complémentaires, notamment XP, et n'est pas défini dans le Scrum Guide. Un spike est un PBI de recherche timeboxé : sa sortie n'est pas du code livré mais une décision documentée — faisabilité d'une approche, performance d'un algorithme, choix d'une librairie. Il protège l'équipe contre les estimations à l'aveugle sur des sujets incertains.
Format typique : « Spike : évaluer la faisabilité d'une recherche vectorielle sur 10 000 produits — 3 jours — livrable : rapport de POC en Sprint Review. »
Enablers
Un enabler est un PBI technique préparatoire qui débloque des fonctionnalités à venir : pipeline ML, infrastructure de paiement, observabilité, sécurisation d'API. Le mot vient du framework SAFe ; en Scrum pur, c'est simplement un PBI à valeur indirecte.
Découpage Epic → User Story → Task
Le découpage classique part d'un Epic (Product Backlog), se décompose en User Stories (Product Backlog) puis en Tasks au moment du Sprint Planning. Les Tasks n'appartiennent pas au Product Backlog : elles vivent dans le Sprint Backlog et restent sous l'autorité exclusive des Developers. Pour voir comment ces PBI s'imbriquent dans un backlog complet, consultez nos exemples de Product Backlog et nos templates prêts à l'emploi.
Critères INVEST
Les critères INVEST (Bill Wake, 2003) sont une grille largement utilisée pour évaluer la qualité d'une User Story. Comme les User Stories elles-mêmes, ils ne sont pas imposés par le Scrum Guide : ce sont des pratiques utiles, pas une exigence de Scrum.
| Critère | Signification | Test concret |
|---|---|---|
| I — Independent | Indépendante des autres stories autant que possible. | Pas de chaîne de dépendances bloquantes. |
| N — Negotiable | Négociable : ce n'est pas un contrat figé, juste une promesse de conversation. | Le PO et les Devs peuvent ajuster le périmètre. |
| V — Valuable | Apporte de la valeur à l'utilisateur ou au business. | On peut expliquer en une phrase pourquoi on la fait. |
| E — Estimable | L'équipe peut l'estimer raisonnablement. | Si elle n'est pas estimable : spike, pas user story. |
| S — Small | Suffisamment petite pour tenir dans un Sprint (idéalement quelques jours). | Au-delà de ~13 SP : certaines équipes choisissent de splitter (accord d'équipe, pas un seuil universel). |
| T — Testable | Des critères d'acceptation clairs et vérifiables existent. | Sans AC, pas de Done possible. |
Critères d'acceptation
Les critères d'acceptation (AC) précisent les conditions à remplir pour qu'un PBI soit considéré comme livrable. Ils complètent la Definition of Done, qui elle s'applique uniformément à tout l'Increment.
| Format | Description | Quand l'utiliser |
|---|---|---|
| Format checklist | Liste à puces de conditions vérifiables. | Rapide à rédiger ; idéal pour PBI simples. |
| Format Gherkin | Given / When / Then — orientée tests automatisés. | Idéal pour BDD ; couvre nominal + erreurs. |
| Format scénarios utilisateur | Cas concrets décrits du point de vue utilisateur. | Très lisible côté métier ; utile pour UX. |
| Format règles métier | Règles formelles + valeurs limites. | Bancaire, assurance, santé : précision exigée. |
Exemple — User Story bancaire (PBI « Activer Face ID ») :
- Le client peut activer Face ID depuis l'écran « Sécurité » en une étape.
- Le fallback PIN reste disponible après 3 échecs biométriques.
- L'activation est journalisée et auditable (conformité bancaire).
- Tests sur iOS 17 + 18 et Android 13 + 14 passent (5 devices min).
Exemples complets par secteur
Cas n°1 — Application bancaire
Contexte : néobanque, équipe Scrum de 6 Developers, Sprints de 2 semaines.
Product Goal : devenir l'application bancaire mobile la mieux notée du marché français.
- PBI 1 — User Story : Activation Face ID (priorité 1, 8 SP). AC : Face ID + empreinte, fallback PIN, audit log.
- PBI 2 — Bug : Crash login Android 12 (priorité 2, 3 SP). AC : crash-free rate > 99,7 %.
- PBI 3 — Dette : Refactor module paiement (priorité 4, 8 SP). AC : couverture tests > 80 %, rollback OK.
- PBI 4 — Spike : Évaluer librairie SCA forte (priorité 5, 3 jours). Livrable : rapport.
- PBI 5 — Enabler : Pipeline mobile CI/CD avec signature app (priorité 6, 13 SP).
Cas n°2 — SaaS B2B
Contexte : CRM, 1 200 clients PME, ARR 8 M€.
Product Goal : réduire le churn annuel de 14 % à 8 % en 12 mois.
- PBI 1 — Epic : Onboarding guidé en 7 étapes (décomposé en 5 User Stories).
- PBI 2 — User Story : Import CSV intelligent (priorité 2, 21 SP). AC : détection auto colonnes, preview, rollback.
- PBI 3 — Non-fonctionnel : Conformité SOC 2 Type II (priorité 3, 21 SP). AC : audit externe passé, SSO SAML.
- PBI 4 — Enabler : API publique v2 (priorité 4, 13 SP). AC : rate limiting, versioning, sandbox.
Cas n°3 — E-commerce
Contexte : pure player mode, 1,2 M visiteurs/mois, conversion 1,8 %.
Product Goal : passer de 1,8 % à 2,6 % de conversion en 2 trimestres.
- PBI 1 — User Story : Checkout invité (priorité 1, 13 SP). AC : paiement Stripe, compte créé a posteriori.
- PBI 2 — User Story : Apple Pay & Google Pay (priorité 2, 8 SP).
- PBI 3 — Spike : Faisabilité recherche vectorielle catalogue (priorité 7, 5 SP, 3 jours).
- PBI 4 — Non-fonctionnel : Accessibilité WCAG AA fiche produit (priorité 6, 13 SP).
Cas n°4 — Application mobile (fitness)
Contexte : 320 000 MAU, freemium.
Product Goal : atteindre 50 000 abonnés Premium en 9 mois.
- PBI 1 — Epic : Programmes d'entraînement personnalisés (IA).
- PBI 2 — User Story : Sync Apple Health & Google Fit (priorité 2, 13 SP).
- PBI 3 — Bug : Sons coupés sur AirPods Pro 2 (priorité 6, 3 SP).
- PBI 4 — Enabler : Téléchargement offline des séances (priorité 4, 8 SP).