A
Adaptation
Troisième pilier de l'empirisme en Scrum : ajustement immédiat du processus ou du produit dès qu'une déviation est détectée au-delà des limites acceptables. Elle permet une correction de trajectoire rapide pour réduire le gaspillage et le risque.
Lors du Daily Scrum, les Developers constatent un retard et adaptent leur plan pour la journée afin de préserver le Sprint Goal.
Artifact Commitment
Engagement formel associé à chaque artefact Scrum : le Product Goal pour le Product Backlog, le Sprint Goal pour le Sprint Backlog, et la Definition of Done pour l'Increment. Ces engagements renforcent la transparence et la focalisation.
L'équipe rappelle que le commitment du Sprint Backlog est le Sprint Goal, et non la liste exhaustive des tâches planifiées.
C
Cross-functional
Caractéristique d'une Scrum Team dont les membres possèdent collectivement toutes les compétences nécessaires pour livrer un Increment complet à chaque Sprint, sans dépendance externe. Il s'agit d'une capacité collective, non individuelle.
La Scrum Team est cross-functional car elle réunit des compétences en développement, test et design, lui permettant de livrer un Increment sans solliciter d'autres équipes.
D
Daily Scrum
Événement Scrum formel de 15 minutes, timeboxé, réservé aux Developers, durant lequel ils inspectent la progression vers le Sprint Goal et adaptent le Sprint Backlog pour les prochaines 24 heures. Ce n'est pas une réunion de reporting.
Chaque matin à 9h00, les Developers tiennent leur Daily Scrum de 15 minutes pour synchroniser leur travail et identifier les impediments.
Definition of Done (DoD)
Description formelle et partagée de l'état qu'un Increment doit atteindre pour répondre aux standards de qualité requis. Elle constitue l'engagement associé à l'Increment et sert de critère de complétude, non de simple liste de vérification.
Un Increment qui ne satisfait pas la Definition of Done ne peut pas être présenté lors de la Sprint Review ni être mis en production.
E
Empiricism
Fondement philosophique de Scrum reposant sur trois piliers — Transparency, Inspection et Adaptation — qui permettent à l'équipe de prendre des décisions basées sur des faits observés plutôt que sur des hypothèses ou des plans prédictifs.
Grâce à l'empirisme, l'équipe inspecte l'Increment à chaque Sprint Review et adapte le Product Backlog en fonction des retours réels des stakeholders.
I
Increment
Résultat concret et utilisable produit durant un Sprint, qui s'ajoute de façon additive aux Increments précédents et constitue une étape vers le Product Goal. Un Sprint peut produire plusieurs Increments, qui doivent tous satisfaire la Definition of Done.
À la fin du Sprint, l'équipe présente un Increment pleinement fonctionnel lors de la Sprint Review, conforme à la Definition of Done.
Inspection
Deuxième pilier de l'empirisme en Scrum : examen régulier des artefacts Scrum et de la progression vers les objectifs afin de détecter rapidement les écarts indésirables. Elle s'applique à chaque événement Scrum formel.
Lors de la Sprint Review, la Scrum Team et les stakeholders inspectent l'Increment pour identifier les ajustements nécessaires au Product Backlog.
L
Lightweight Framework
Caractérisation officielle de Scrum comme un cadre minimal et délibérément incomplet, définissant uniquement les rôles, événements et artefacts essentiels sans prescrire les pratiques techniques d'implémentation. Cette légèreté permet l'adaptation au contexte.
Scrum est un lightweight framework, c'est pourquoi il ne prescrit pas l'utilisation de TDD ou de l'intégration continue, laissant ces choix techniques aux Developers.
P
Product Backlog
Artefact Scrum vivant et ordonné listant tout ce qui est nécessaire pour améliorer le produit. Il est géré exclusivement par le Product Owner et évolue continuellement selon les retours du marché, des clients et de l'équipe.
Après la Sprint Review, le Product Owner met à jour le Product Backlog en intégrant les feedbacks des stakeholders et en réordonnant les items selon la valeur métier.
Product Goal
Objectif à long terme décrivant l'état futur souhaité du produit, constituant l'engagement associé au Product Backlog. Il guide les décisions et la planification de la Scrum Team, et un seul Product Goal peut être poursuivi à la fois.
La Scrum Team aligne chaque Sprint Goal avec le Product Goal pour s'assurer que chaque Sprint contribue à la vision stratégique du produit.
Product Owner
Rôle au sein de la Scrum Team, seul responsable de la gestion du Product Backlog et de la maximisation de la valeur du produit. Il représente l'ensemble des stakeholders et est le seul habilité à annuler un Sprint.
Le Product Owner ordonne le Product Backlog selon la valeur métier et clarifie les exigences auprès des Developers tout au long du Sprint.
R
Refinement
Activité continue — non un événement Scrum formel — consistant à décomposer et préciser les items du Product Backlog pour leur ajouter des détails, des estimations et de l'ordre, afin de les préparer pour les prochains Sprint Plannings.
Pendant le Sprint, le Product Owner et les Developers consacrent du temps au Refinement pour s'assurer que les prochains items du Product Backlog sont suffisamment clairs avant le Sprint Planning.
S
Scrum Master
Rôle au sein de la Scrum Team agissant en servant-leader : il coache l'équipe vers l'auto-gestion, facilite les événements Scrum, supprime les impediments et aide l'organisation à adopter Scrum. Il ne dirige pas le travail des Developers.
Le Scrum Master intervient auprès des stakeholders qui demandent des rapports quotidiens pour leur expliquer les mécanismes de transparence de Scrum comme la Sprint Review.
Scrum Values
Les cinq valeurs fondamentales de Scrum — Commitment, Courage, Focus, Openness et Respect — qui guident les comportements et décisions de la Scrum Team, créant la confiance et la transparence nécessaires à une collaboration efficace.
En faisant preuve de Courage, un Developer soulève un impediment difficile lors du Daily Scrum plutôt que de le dissimuler, incarnant ainsi les Scrum Values.
Self-managing
Caractéristique collective d'une Scrum Team qui décide de manière autonome qui fait quoi, dans quel ordre et comment, sans directive externe. Cela diffère de l'autonomie individuelle et s'applique à l'équipe dans son ensemble.
La Scrum Team est self-managing : c'est elle qui décide de la répartition des tâches du Sprint Backlog sans que le Scrum Master ou le Product Owner n'imposent d'assignations.
Servant Leadership
Style de leadership incarné par le Scrum Master, qui sert l'équipe en facilitant, en coachant et en supprimant les obstacles plutôt qu'en commandant ou en contrôlant. Il place les besoins de l'équipe au-dessus des siens.
En tant que servant-leader, le Scrum Master aide le Product Owner à améliorer ses techniques de gestion du Product Backlog plutôt que de prendre des décisions à sa place.
Sprint
Événement conteneur timeboxé d'un mois maximum, au cours duquel tous les autres événements Scrum se déroulent et durant lequel un Increment utilisable est créé. Les Sprints sont consécutifs, sans interruption entre eux.
Dès la fin du Sprint Retrospective, le nouveau Sprint démarre immédiatement, garantissant une cadence de livraison continue.
Sprint Backlog
Artefact Scrum appartenant aux Developers, composé du Sprint Goal (pourquoi), des Product Backlog items sélectionnés (quoi) et d'un plan d'action pour livrer l'Increment (comment). Il est créé et adapté par les Developers tout au long du Sprint.
Les Developers mettent à jour le Sprint Backlog quotidiennement après le Daily Scrum pour refléter l'avancement réel et les ajustements de plan.
Sprint Goal
Objectif unique et cohérent établi lors du Sprint Planning par l'ensemble de la Scrum Team, constituant l'engagement du Sprint Backlog. Il guide le Sprint et ne peut pas être modifié une fois le Sprint commencé.
Lorsque les Developers réalisent qu'ils ont trop de travail, ils négocient le périmètre avec le Product Owner tout en préservant le Sprint Goal intact.
Sprint Planning
Premier événement formel d'un Sprint, timeboxé à 8 heures maximum pour un Sprint d'un mois, durant lequel toute la Scrum Team définit le Sprint Goal et sélectionne les Product Backlog items à réaliser. C'est le seul moment où le Sprint Goal est établi.
Lors du Sprint Planning, le Product Owner présente les items prioritaires du Product Backlog et l'équipe définit collaborativement le Sprint Goal pour les deux semaines à venir.
Sprint Retrospective
Dernier événement formel du Sprint, timeboxé à 3 heures pour un Sprint d'un mois, réservé à toute la Scrum Team pour inspecter ses processus, interactions et outils, et planifier des améliorations concrètes pour le prochain Sprint.
Lors de la Sprint Retrospective, l'équipe identifie que les revues de code prennent trop de temps et décide d'introduire des pair-programming sessions dès le prochain Sprint.
Sprint Review
Événement formel timeboxé à 4 heures pour un Sprint d'un mois, au cours duquel la Scrum Team et les stakeholders inspectent l'Increment et collaborent sur les adaptations du Product Backlog. Ce n'est pas une réunion de statut mais une session de travail interactive.
Lors de la Sprint Review, les stakeholders testent les nouvelles fonctionnalités et suggèrent des ajustements que le Product Owner intègre dans le Product Backlog révisé.
T
Timebox
Durée maximale fixe allouée à chaque événement Scrum, qui ne peut pas être prolongée. Le timeboxing crée une cadence prévisible, limite les risques liés aux dépassements et force la focalisation sur l'essentiel.
Le Daily Scrum est timeboxé à 15 minutes : si une discussion technique s'éternise, le Scrum Master encourage l'équipe à la reporter après l'événement pour respecter le timebox.
Transparency
Premier pilier de l'empirisme en Scrum : le processus émergent et le travail doivent être visibles pour ceux qui réalisent le travail et ceux qui le reçoivent. Elle permet des prises de décision éclairées et renforce la responsabilité collective.
Le Product Owner maintient un Product Backlog visible et ordonné pour assurer la Transparency de la stratégie produit auprès des Developers et des stakeholders.