Definition of Done et critères d'acceptation

Définition

La Definition of Done (DoD) est un accord d'équipe définissant les conditions qu'un incrément doit remplir pour être considéré comme terminé et potentiellement livrable. Les critères d'acceptation sont les conditions spécifiques à chaque User Story, définies par le Product Owner, pour qu'elle soit acceptée.

Aspect	Definition of Done	Critères d'acceptation
Portée	Globale — s'applique à tout incrément	Locale — spécifique à une User Story
Défini par	L'équipe Scrum (consensus)	Le Product Owner
Niveau	Qualité et processus	Fonctionnalité et comportement
Modifiable	Rarement (amélioré à chaque rétrospective)	À chaque story
Exemple	Tests unitaires > 80%, revue de code faite	Le filtre affiche les résultats en < 2 secondes

Contexte

Le CAPM distingue clairement DoD et critères d'acceptation — c'est un piège d'examen fréquent. La DoD garantit la qualité technique, les critères d'acceptation garantissent la valeur métier. Un incrément doit satisfaire les deux pour être considéré comme terminé.

Détails techniques

Definition of Done — Exemple complet

Catégorie	Critère DoD
Code	Code compilé sans erreur
Code	Revue de code par au moins 1 pair
Tests	Tests unitaires écrits et passants (couverture ≥ 80%)
Tests	Tests d'intégration passants
Documentation	Documentation API mise à jour
Déploiement	Déployé en environnement de staging
Performance	Temps de réponse < 200 ms sous charge standard
Sécurité	Scan de vulnérabilités passé (aucune critique)

Critères d'acceptation — Format Given/When/Then

User Story : En tant que client, je veux filtrer les produits par prix

Critère 1 :
  GIVEN  je suis sur la page catalogue
  WHEN   je définis un filtre entre 10€ et 50€
  THEN   seuls les produits dans cette fourchette s'affichent

Critère 2 :
  GIVEN  je suis sur la page catalogue
  WHEN   je définis un filtre de 0€ à 0€
  THEN   un message « Aucun résultat » s'affiche

Critère 3 :
  GIVEN  j'ai un filtre prix actif
  WHEN   je clique sur « Réinitialiser »
  THEN   tous les produits s'affichent à nouveau

Relation DoD ↔ Critères d'acceptation

User Story terminée ?
      │
      ├── Critères d'acceptation remplis ? ── NON ──→ Story non acceptée
      │           │
      │          OUI
      │           │
      ├── Definition of Done respectée ? ── NON ──→ Story non terminée
      │           │                                  (dette technique)
      │          OUI
      │           │
      └───────── ✓ Story = DONE
                  → Incluse dans l'incrément livrable

Évolution de la DoD

Phase d'équipe	DoD typique	Raison
Équipe nouvelle	Basique (compile, tests manuels OK)	Équipe en apprentissage
Équipe mature	Complète (tests auto, CI/CD, revue, docs)	Processus maîtrisé
Scaling (SAFe)	DoD d'équipe + DoD de système + DoD de solution	Intégration multi-équipes

Piège d'examen : Une story qui passe les critères d'acceptation mais ne respecte pas la DoD n'est PAS terminée. Elle ne peut pas être incluse dans l'incrément présenté en Sprint Review.

Anti-patterns

Anti-pattern	Problème	Solution
Pas de DoD formalisée	Qualité variable d'un sprint à l'autre	L'équipe définit une DoD dès le Sprint 1
DoD trop laxiste	Dette technique accumulée	Renforcer progressivement via les rétros
Critères d'acceptation vagues	Désaccord PO/équipe sur le « fini »	Format Given/When/Then systématique
Ignorer la DoD sous pression	Livraison de code instable	Le Scrum Master protège la DoD

Exemple concret

Sprint Review — le PO examine 3 stories :

Story	Critères d'acceptation	DoD	Verdict
US-21 : Filtre par régime	✅ 3/3 critères validés	✅ Tests 85%, revue faite, staging OK	DONE — dans l'incrément
US-22 : Itinéraire livreur	✅ 4/4 critères validés	❌ Tests à 65% (seuil = 80%)	NOT DONE — retourne dans le backlog
US-23 : Modification menu	❌ 2/3 critères (temps de réponse > 2s)	✅ Tous les critères DoD	NOT DONE — retourne dans le backlog

US-22 et US-23 retournent dans le Product Backlog. L'équipe discute en rétrospective comment améliorer la couverture de tests.