Backlog et User Stories

Définition

Le Product Backlog est la liste ordonnée et évolutive de tout ce qui est nécessaire au produit. Il est la source unique des exigences. Chaque élément est exprimé sous forme de User Story — un besoin formulé du point de vue de l'utilisateur selon le format : « En tant que [rôle], je veux [action], afin de [bénéfice] ».

Élément	Description
Product Backlog	Liste priorisée de toutes les fonctionnalités, corrections et améliorations
User Story	Format d'expression d'un besoin centré utilisateur
Epic	Grande User Story à décomposer en stories plus petites
Theme	Regroupement logique d'epics ou stories sur un même sujet
Spike	Tâche de recherche ou prototypage pour réduire l'incertitude

Contexte

Le CAPM teste la compréhension du backlog comme outil central de la planification adaptative. Contrairement à un cahier des charges prédictif figé, le backlog évolue constamment — c'est un artefact vivant. Le Product Owner en est le seul responsable, même s'il sollicite les retours de l'équipe et des parties prenantes.

Détails techniques

Hiérarchie du backlog

Thèmes
  └── Epics
        └── User Stories
              └── Tâches techniques (Sprint Backlog)

Exemple :
Thème : Gestion des comptes
  └── Epic : Inscription utilisateur
        ├── Story : Créer un compte avec email
        ├── Story : Connexion via Google
        └── Story : Réinitialiser mot de passe
              ├── Tâche : Développer API reset
              ├── Tâche : Créer template email
              └── Tâche : Tests unitaires

Modèle INVEST pour les User Stories

Critère	Signification	Vérification
Indépendante	Pas de dépendance avec d'autres stories	Peut être développée et livrée seule
Négociable	Détails négociés avec le PO	Pas un contrat rigide
Valuable	Apporte de la valeur à l'utilisateur	Le PO peut expliquer le « pourquoi »
Estimable	L'équipe peut estimer l'effort	Suffisamment comprise
Small (Petite)	Réalisable en un sprint	1 à quelques jours de travail
Testable	Critères d'acceptation vérifiables	On sait quand c'est « fini »

Structure d'une User Story

Section	Contenu	Exemple
Titre	Résumé court	Inscription par email
Story	Format As a / I want / So that	En tant qu'utilisateur, je veux créer un compte avec mon email, afin d'accéder à mes commandes
Critères d'acceptation	Conditions de validation	Email validé, mot de passe ≥ 8 caractères, confirmation envoyée
Points d'effort	Estimation relative (story points)	5 points
Priorité	Position dans le backlog	Haute

Techniques d'estimation du backlog

Technique	Description	Quand l'utiliser
Planning Poker	L'équipe vote simultanément avec des cartes Fibonacci	Estimation d'un sprint backlog
T-shirt sizing	S, M, L, XL — estimation rapide relative	Estimation grossière d'un backlog large
Affinité groupée	Regrouper les stories par taille similaire	Tri initial d'un grand nombre de stories
Dot voting	Points de vote pour prioriser	À combiner avec d'autres techniques

Le backlog refinement (grooming) est l'activité continue de :

Décomposer les epics en stories
Clarifier les critères d'acceptation
Estimer ou ré-estimer les stories
Réordonner selon les priorités

Règle PMI : Le refinement ne doit pas dépasser 10% de la capacité d'un sprint.

Exemple concret

Backlog d'une application de livraison de repas — Sprint 4 :

#	User Story	Points	Priorité	Statut
US-21	En tant que client, je veux filtrer par régime alimentaire	5	Haute	Sprint Backlog
US-22	En tant que livreur, je veux voir l'itinéraire optimisé	8	Haute	Sprint Backlog
US-23	En tant que restaurateur, je veux modifier mon menu en temps réel	3	Moyenne	Product Backlog
US-24	En tant que client, je veux noter ma livraison	2	Faible	Product Backlog
SP-03	Spike : Évaluer l'API de cartographie Mapbox vs Google Maps	3	Haute	Sprint Backlog

Capacité du sprint = 21 points → US-21 (5) + US-22 (8) + SP-03 (3) = 16 points sélectionnés, marge de 5 points pour imprévus.

Backlog Et User Stories