L'empirisme est le cœur philosophique de Scrum. Ce guide est conçu pour devenir la meilleure ressource francophone sur le contrôle empirique du processus défini par le Scrum Guide 2020 et vous préparer aux questions PSM I les plus discriminantes de l'examen.
Qu'est-ce que l'empirisme dans Scrum ?
Le Scrum Guide 2020 ouvre sa théorie par cette affirmation : « Scrum est fondé sur l'empirisme et le lean thinking. L'empirisme affirme que la connaissance vient de l'expérience et que les décisions se prennent à partir de ce qui est observé. » Trois piliers soutiennent cette posture : transparence, inspection, adaptation.
L'empirisme s'oppose à l'approche prédictive : au lieu de planifier intégralement un produit avant de le construire, on construit par petits incréments, on observe le résultat réel, puis on ajuste. Cette boucle se répète chaque Sprint.
Trois piliers indissociables — retirez-en un et l'empirisme s'effondre.
Pourquoi Scrum est fondé sur l'empirisme
Le développement de produits complexes est par nature imprévisible :
- Le besoin évolue à mesure que les utilisateurs voient le produit.
- La solution n'est pas connue tant qu'on ne l'a pas essayée.
- La technologie change en cours de route.
- Le marché bouge indépendamment du plan initial.
Face à cette incertitude, planifier intégralement à l'avance produit des plans faux. L'empirisme propose l'inverse : avancer par petits cycles, mesurer, ajuster. C'est moins rassurant sur le papier, mais massivement plus efficace en situation réelle.
Empirisme vs planification prédictive
| Critère | Approche prédictive (cascade) | Approche empirique (Scrum) |
|---|---|---|
| Hypothèse | Le besoin et la solution sont connus | L'incertitude est dominante |
| Plan | Détaillé en amont, peu modifié | Émergent, ajusté chaque Sprint |
| Mesure du progrès | Avancement par rapport au plan | Increment réel produit et inspecté |
| Réduction du risque | Tardive (recette finale) | Continue (à chaque Sprint) |
| Décision | Sur les prévisions | Sur ce qui est observé |
| Adaptation | Coûteuse, formalisée | Naturelle, intégrée au cycle |
Les trois piliers empiriques de Scrum
Le Scrum Guide 2020 énonce explicitement les trois piliers : transparence, inspection, adaptation. Ils sont indissociables : retirer l'un détruit la valeur des deux autres.
Transparence
Le processus et le travail doivent être visibles à la fois pour ceux qui exécutent et pour ceux qui reçoivent. La transparence dans Scrum repose sur :
- Un Product Backlog ordonné et compréhensible.
- Un Sprint Backlog reflétant le travail planifié réel.
- Un Increment conforme à la Definition of Done.
- Un standard partagé de « terminé » (la DoD).
Inspection
Les artefacts Scrum et la progression vers les objectifs convenus doivent être inspectés fréquemment et avec diligence pour détecter les écarts potentiellement indésirables. Chaque inspection compare un artefact à son engagement :
- Product Backlog ↔ Product Goal
- Sprint Backlog ↔ Sprint Goal
- Increment ↔ Definition of Done
Adaptation
Si une inspection révèle un écart inacceptable, le processus ou le matériel doit être adapté sans tarder. Le Scrum Guide insiste : l'adaptation doit être immédiate pour éviter une dérive supplémentaire.
| Pilier | Question clé | Sans ce pilier |
|---|---|---|
| Transparence | L'information est-elle visible et fiable ? | L'inspection se fait sur des données fausses. |
| Inspection | Sommes-nous toujours alignés sur l'engagement ? | Les écarts deviennent invisibles. |
| Adaptation | Que devons-nous changer maintenant ? | L'écart se creuse et le coût explose. |
Lien avec les Scrum Events
Les cinq Scrum Events ne sont pas des réunions de coordination : ce sont des opportunités formelles d'inspection et d'adaptation. C'est leur raison d'être.
Chaque événement = une opportunité formelle d'inspection et d'adaptation.
| Événement | Artefact inspecté | Engagement de référence | Adaptation typique |
|---|---|---|---|
| Sprint Planning | Product Backlog | Product Goal | Sélection des PBI, formulation du Sprint Goal |
| Daily Scrum | Sprint Backlog | Sprint Goal | Plan ajusté pour les 24 h suivantes |
| Sprint Review | Increment + Product Backlog | Product Goal | Réordonnancement du Product Backlog |
| Sprint Retrospective | Scrum Team (process) | Definition of Done, qualité | Améliorations dès le Sprint suivant |
| Sprint (conteneur) | Tous les artefacts | Tous les engagements | Décision d'annulation possible si le Sprint Goal devient obsolète |
Lien avec les Scrum Artifacts
Les trois artefacts Scrum existent pour maximiser la transparence des informations clés. Chacun est associé à un engagement qui sert de référence à l'inspection.
| Artefact | Engagement | Ce que la transparence rend possible |
|---|---|---|
| Product Backlog | Product Goal | Décider de la prochaine étape produit la plus utile. |
| Sprint Backlog | Sprint Goal | Inspecter quotidiennement la progression vers le Goal. |
| Increment | Definition of Done | Inspecter une valeur réelle, pas une promesse. |
Lien avec les engagements : Product Goal, Sprint Goal, Definition of Done
Sans engagement, un artefact n'est qu'une liste : impossible d'inspecter une « liste » contre rien. Les engagements donnent l'aune de mesure qui rend l'empirisme opérationnel.
- Product Goal — direction long terme du produit. Il guide le contenu du Product Backlog.
- Sprint Goal — promesse unique du Sprint. Il aligne le travail des Developers.
- Definition of Done — qualité partagée. Elle définit ce qui peut être appelé Increment.
Lien avec la Sprint Review
La Sprint Review est l'événement empirique par excellence côté produit : on présente l'Increment réel à des stakeholders réels et on adapte le Product Backlog en conséquence.
Sans adaptation du Product Backlog, la Review se résume à une démo — l'empirisme est rompu.
Lien avec la Sprint Retrospective
La Sprint Retrospective est l'événement empirique côté process : on inspecte la Scrum Team (interactions, outils, Definition of Done, qualité), et on identifie des améliorations concrètes à appliquer dès le prochain Sprint.
Lien avec le Daily Scrum
Le Daily Scrum est l'acte quotidien d'empirisme : les Developers inspectent leur progression vers le Sprint Goal et adaptent le Sprint Backlog pour les 24 h suivantes.
Le Daily Scrum n'est pas un reporting : c'est un acte d'empirisme quotidien.
Lien avec le Product Backlog
Le Product Backlog est l'artefact le plus dynamique : il évolue à chaque inspection (Review, refinement, Daily si nécessaire). Il est la mémoire vivante de l'empirisme appliqué au produit.
Pourquoi l'empirisme réduit le risque
Un projet géré en cascade concentre tout le risque à la fin : la recette finale révèle d'un coup les écarts entre ce qui a été imaginé et ce qui a été construit. Un projet empirique le distribue : chaque Sprint réduit une portion d'inconnu.
- Inspection régulière ⇒ écarts détectés tôt.
- Adaptation rapide ⇒ coût de correction minimal.
- Increment fréquent ⇒ valeur livrée même en cas d'arrêt anticipé.
- Sprint Goal court ⇒ promesse modeste, atteignable, vérifiable.
Pourquoi Scrum exige des décisions basées sur ce qui est observé
Les décisions Scrum sont prises à partir de preuves observables : un Increment qui tourne, un feedback de stakeholder, un indicateur réel. Pas à partir d'opinions, de désirs ou d'estimations non vérifiées.
Exigences du Scrum Guide 2020
- « Scrum est fondé sur l'empirisme et le lean thinking. »
- Trois piliers explicites : transparence, inspection, adaptation.
- Les artefacts doivent être transparents pour permettre l'inspection.
- L'inspection doit être fréquente et diligente.
- L'adaptation doit avoir lieu dès que possible pour minimiser la dérive.
- Chaque événement Scrum est une opportunité formelle d'inspection et d'adaptation.
Exemple complet — application bancaire
Une Scrum Team développe une nouvelle application bancaire mobile en Sprints de deux semaines. Voici comment l'empirisme se matérialise concrètement sur un Sprint.
| Étape | Ce qui se passe |
|---|---|
| Hypothèse produit | Le PO suppose que les utilisateurs souhaitent payer par QR code en magasin. Aucune preuve réelle pour l'instant. |
| Sprint Goal | « Permettre à un client de payer un commerçant via QR code, jusqu'à 200 €, en moins de 5 secondes. » |
| Increment livré | Une fonctionnalité QR end-to-end, conforme à la Definition of Done, testée sur 5 commerçants pilotes. |
| Feedback Sprint Review | Les commerçants apprécient mais demandent un retour visuel plus fort. Trois clients pilotes signalent une crainte de fraude. |
| Adaptation du Product Backlog | Le PO insère deux PBI : « animation de confirmation » et « écran de réassurance fraude ». Il dépriorise « QR multi-devise » prévu pour le Sprint 14. |
| Sprint Retrospective | L'équipe ajoute « test sécurité fraude » à la Definition of Done et décide de découper les futurs PBI critiques en tranches plus fines. |
| Sprint 13 (immédiatement après) | Le Sprint Planning reprend les apprentissages. L'hypothèse initiale a été validée — partiellement — et raffinée par l'observation. |
Erreurs fréquentes au PSM I
| Symptôme | Pourquoi c'est faux empiriquement | Bon réflexe |
|---|---|---|
| « On planifie 6 mois en détail avant de commencer. » | L'empirisme rejette la planification prédictive intégrale. | Plan émergent, raffiné Sprint après Sprint. |
| « On ne montre l'Increment qu'à la fin du projet. » | Pas d'inspection régulière = pas d'adaptation. | Sprint Review à chaque fin de Sprint. |
| « Le Daily Scrum est un reporting au manager. » | Détruit la transparence et l'ownership. | Daily appartient aux Developers, inspecte le Sprint Goal. |
| « On skip la Retrospective ce Sprint, pas le temps. » | Pas d'adaptation du process = stagnation. | Réduire le scope, jamais l'événement. |
| « Les stakeholders ne sont pas invités à la Review. » | Pas d'inspection externe = pas de feedback réel. | PO invite activement les bonnes parties prenantes. |
| « On change le Sprint Goal en cours de Sprint quand ça arrange. » | Détruit la stabilité empirique du Sprint. | Le Sprint Goal ne change pas ; on adapte le plan, pas le Goal. |
| « La Definition of Done est implicite. » | Sans DoD partagée, pas d'inspection objective de l'Increment. | DoD explicite, partagée, vérifiable. |
15 questions PSM I
FAQ — questions fréquentes
Retrouvez plus bas, dans la section FAQ structurée, les réponses aux dix questions les plus posées sur l'empirisme dans Scrum.
Références
- Scrum Guide 2020 — Ken Schwaber & Jeff Sutherland, novembre 2020.
- Scrum.org — documentation officielle, parcours PSM I.
- Ken Schwaber, co-auteur du Scrum Guide.
- Jeff Sutherland, co-auteur du Scrum Guide.
À lire aussi
Source officielle : Scrum Guide 2020.