Artefacts Scrum, User Stories & Product Backlog — Les Fondamentaux • Ressources

Rappel : Les artefacts Scrum sont les supports de la transparence (inspection → adaptation). La DoD en est le contrat de qualité. Les User Stories sont le langage commun entre métier et technique.

1. Les 3 Artefacts Scrum + Definition of Done

Artefact	C’est quoi ?	Propriétaire	Règle d’or
Product Backlog	Liste unique, ordonnée, de tout ce qui est nécessaire au produit	Product Owner (PO)	Ordonné par valeur métier (DEEP)
Sprint Backlog	Plan de l’équipe pour le Sprint (US + tâches < 1 jour)	La Squad	Seule la Squad le modifie
Incrément	Somme des US « Done » conformes à la DoD	La Squad (créé) / PO (livre)	100% DoD ou retour au Backlog
Definition of Done (DoD)	Grille qualité non négociable : 100% = Done, 99% = Pas Done	Scrum Team (consensus)	Partagée, explicite, évolutive

Piliers de l’Empirisme : Transparence • Inspection • Adaptation

1. Product Backlog — Le Réservoir Unique

C’est quoi ? Liste unique, ordonnée, évolutive de tout ce qui est nécessaire au produit. Source unique de vérité.

Propriétaire : Product Owner (PO) — seul décideur de l’ordre, du contenu, de la disponibilité.

Qualité DEEP :

Detailed : détaillé selon la proximité (prêt = détaillé)
Emergent : évolue en continu (ajout/suppression/réordre)
Estimated : chaque US estimée (Planning Poker, T-shirt sizes)
Prioritized : ordonné par valeur métier décroissante (PO décide)

Contenu : User Stories (US), Épopées (Epics), Bugs/Dette technique, Améliorations techniques, Spikes.

Refinement (Grooming) : Activité continue (~10% du temps Sprint) — découpage, estimation, clarification, nettoyage.

2. Sprint Backlog — Le Plan de l’Équipe

C’est quoi ? Sélection d’US du Product Backlog + plan technique (tâches < 1 jour) + suivi visuel (Kanban).

Propriétaire exclusif : La Squad — seule à pouvoir le modifier.

Composition : Sprint Goal + US sélectionnées + tâches techniques (< 1 jour) + Kanban (À faire / En cours / Fait).

Règles strictes :

✅ Seule la Squad le modifie
✅ Tâches < 1 jour (idéalement ½ journée)
✅ Visible par tous (Kanban physique ou numérique)
❌ PO ne touche pas au Sprint Backlog
❌ Pas d’ajout d’US en cours de Sprint (sauf accord unanime + capacité)

3. Incrément — Le Livrable Réel

C’est quoi ? Somme de toutes les US « Done » conformes à la DoD (Sprint actuel + précédents).

Critères : Fonctionnel (démo live), Intégré, Testé, Documenté, Potentiellement déployable.

Propriétaire : La Squad (créé) / PO (décide de livrer).

Règle d’or : Incrément = Somme des US « Done » = 100% DoD — 99% = Pas Done = retour au Backlog.

4. Definition of Done (DoD) — Le Gardien de la Qualité

C’est quoi ? Liste de critères explicites, partagés, non négociables pour considérer un travail comme « Terminé ».

Caractéristiques : Partagée • Explicite (écrite, affichée) • Non négociable (100% = Done, 99% = Pas Done) • Évolutive • Vérifiable objectivement.

Exemple DoD type (équipe Web) :

Code : Code review pair approuvée, lint OK, pas de TODO/FIXME
Tests : Unitaires > 80%, intégration critiques OK, AC passent
Doc : README à jour, commentaires code complexe, changelog
Qualité : Lint/Sonar 0 erreur, pas de console.log, deps à jour
Déploiement : CI/CD vert, déployable staging 1-clic, rollback possible

DoD vs Acceptance Criteria (AC) :

DoD = Globale (toutes US), qualité globale, écrite par Scrum Team
AC = Par US (spécifique), fonctionnalité attendue, écrit par PO + Squad

3. User Stories — L’Atome de Besoin

Format standard :

En tant que [Persona / Rôle]
Je veux [Fonctionnalité concrète]
Afin de [Valeur métier / Bénéfice]

✅ Bonne US	❌ Mauvaise US
`En tant qu'acheteur, je veux payer par carte afin de finaliser ma commande rapidement.`	`En tant que système, je veux traiter le paiement pour mettre à jour la BDD.`

Structure complète d’une US :

Champ	Exemple
ID	`US-124`
Titre	`Paiement par carte bancaire`
Épopée parente	`EPIC-PAIEMENT`
Persona	`Acheteur`
Action	`Payer par carte bancaire`
Valeur	`Finaliser commande rapidement`
Critères d’Acceptation (AC)	Voir ci-dessous
Estimation	`5 pts` / `M`
Dépendances	`US-120 (API paiement)`

4. Critères d’Acceptation (AC) — Le Contrat US/PO

Format Gherkin (Given/When/Then) :

Donné que [contexte initial]
Quand [action utilisateur]
Alors [résultat observable et mesurable]

Exemple : US Paiement Carte

AC1 : Donné que l'acheteur a un panier valide (> 0€)
      Quand il choisit « Carte » et saisit un numéro valide
      Alors la transaction est autorisée et la commande confirmée.

AC2 : Donné que l'acheteur saisit un numéro invalide
      Quand il valide
      Alors un message d'erreur clair s'affiche et la commande n'est pas créée.

Checklist AC : Testable • Non ambigu • Complet (nominal + erreurs + limites) • Indépendant • Négociable.

5. Critères INVEST — Qualité d’une User Story

Lettre	Critère	Question Test	Conforme
Independent	Indépendante des autres US ?	Peut se développer/tester seule	Oui
Negotiable	Détail négociable ?	Le « comment » laissé à la Squad	Oui
Valuable	Apporte de la valeur ?	Utilisateur y gagne qqch	Oui
Estimable	L’équipe peut estimer ?	Complexité compréhensible	Oui
Small	Tient dans 1 Sprint ?	≤ 1 Sprint (idéalement ≤ 1/2)	Oui
Testable	AC vérifiables ?	Given/When/Then automatisable	Oui

Règle : US non-INVEST = retour au Refinement, pas en Sprint Planning.

5. Épopées & Découpage (Slicing)

Épopée (Epic) : Besoin fonctionnel majeur trop gros pour 1 Sprint. Découpé en plusieurs User Stories (US).

Slicing Vertical (tranches traversant UI→API→BDD) — PAS horizontal :

Technique	Exemple (Épopée « Paiement »)
Par Règles Métier	US1: CB Visa/Mastercard, US2: Amex, US3: 3D Secure
Par Persona	US1: Client connecté, US2: Invité (guest)
Par Plateforme	US1: Web, US2: Mobile, US3: API
Par Données	US1: Montant fixe, US2: Variable, US3: Multi-devises
Par Workflow	US1: Saisie carte, US2: 3D Secure, US3: Confirmation

Propriétaire unique : Product Owner (seul décideur ordre/contenu/disponibilité).

Qualité DEEP :

Critère	Action
Detailed	Détail selon proximité (prêt = détaillé)
Emergent	Évolue en continu (ajout/suppression/réordre)
Estimated	Toute US estimée (Planning Poker, T-shirt sizes)
Prioritized	Ordonnée par valeur métier (PO décide)

États d’une US

[Idée] → [Ébauche] → [Raffinée] → [Estimée] → [Prête (Ready)] → [Sprint Backlog] → [Done]

Definition of Ready (DoR) — Checklist Entrée Sprint

☐ INVEST respecté
☐ AC rédigés (Given/When/Then complets)
☐ Estimée (Planning Poker)
☐ Dépendances identifiées / résolues
☐ Taille ≤ 1 Sprint (idéalement ≤ 50%)
☐ UI/UX prêt (maquettes validées)
☐ Architecture tranchée
☐ Données de test identifiées

Règle : US non « Ready » = pas en Sprint Planning.

Ce N’EST PAS un événement officiel mais pratique recommandée (~10% temps Sprint).

Sprint	Fréquence	Durée
1 sem	1×/sem	30-45 min
2 sem	1×/sem	1h
1 mois	1×/sem	1-2h

Activités : Découpage (slicing vertical) → Clarification AC → Estimation (Planning Poker) → Priorisation → Nettoyage → Dépendances.

Planning Poker : Estimation collégiale en points (1,2,3,5,8,13,21,?,☕) = effort total (complexité + incertitude + volume), pas durée.

Tableau Mémo (Fiche Examen)

Concept	Point Clé
3 Artefacts Scrum	Product Backlog, Sprint Backlog, Incrément
Product Backlog	Propriétaire = PO, ordonné par valeur, DEEP
Sprint Backlog	Propriétaire = Squad, plan technique du Sprint
Incrément	Somme des US Done = 100% DoD
DoD	Liste critères qualité pour « Fini » — 100% = Done, 99% = Pas Done
DoD vs AC	DoD = globale (qualité), AC = par US (fonctionnel)
Product Backlog	Propriétaire = PO, ordonné par valeur, DEEP
Sprint Backlog	Propriétaire = Squad, plan technique du Sprint
User Story Format	`En tant que [Persona] — Je veux [Action] — Afin de [Valeur]`
INVEST	Independent, Negotiable, Valuable, Estimable, Small, Testable
AC Format	Given / When / Then (contexte, action, résultat)
DEEP	Detailed, Emergent, Estimated, Prioritized (Backlog)
DoR (Ready)	INVEST + AC + Estimée + Dépendances OK + Taille OK + UI/Architecture prête
Product Backlog	Propriétaire = PO, ordonné par valeur, DEEP
Sprint Backlog	Propriétaire = Squad, plan technique du Sprint
Refinement	~10% temps Sprint, continu, pas événement officiel
Planning Poker	Estimation collégiale = effort total (complexité + incertitude + volume)

Anti-Patterns Essentiels (Pièges à Éviter)

Anti-Pattern	Symptôme	Correction
US « Technique »	`En tant que dev, je veux refactorer...`	Recentrer sur valeur utilisateur
US Trop Grosse	> 1 Sprint (ex: 21 pts)	Découper (slicing vertical)
AC Manquants	US acceptée sans AC	DoR : AC obligatoires (Gherkin)
Dépendances Cachées	US bloquée en Sprint par autre US	Identifier dépendances au Refinement
Backlog « Poubelle »	200+ items non triés	Nettoyage régulier, suppression obsolètes
PO Seul	PO écrit seul, Squad découvre en Planning	Refinement collaboratif (PO + Squad)
Estimation en Heures	« 4 heures » au lieu de points	Points d’effort (complexité + incertitude)
99% DoD = Done	« Presque fini » accepté	Binaire : 100% DoD ou retour Backlog
PO touche Sprint Backlog	PO ajoute des tâches/US	Sprint Backlog = propriété exclusive Squad

Pour l’oral E4/E5 : Les artefacts sont les supports de la transparence (pas de transparence = pas d’inspection = pas d’adaptation). La DoD est le contrat de qualité de l’équipe. L’art de l’US n’est pas l’écriture, c’est le découpage (slicing vertical) et la conversation avec le PO et la Squad. Une US n’est pas une spécification, c’est une invitation à la conversation.

Artefacts Scrum, User Stories & Product Backlog — Les Fondamentaux