B
Backlog Refinement
Activité continue par laquelle l'équipe de développement et le Product Owner clarifient, estiment et ordonnent les éléments du Product Backlog afin qu'ils soient suffisamment compris et actionnables pour le Sprint Planning.
Lors du Backlog Refinement, l'équipe de développement aide à décomposer et estimer les items avant le prochain Sprint Planning pour garantir leur faisabilité.
Burndown Chart
Outil de visualisation représentant la quantité de travail restante dans le temps ; une courbe de tendance sur un release burndown chart projette la date de livraison probable en supposant que le Product Backlog et la capacité de l'équipe restent constants.
La trendline du release burndown chart indique que l'équipe terminera le travail deux Sprints plus tard que prévu si la vélocité reste inchangée.
C
Component Team
Équipe organisée autour d'une seule couche technique ou fonctionnelle (ex. : frontend, base de données, tests), par opposition à une équipe cross-fonctionnelle capable de livrer de la valeur de bout en bout.
L'organisation a dû migrer ses component teams vers des équipes cross-fonctionnelles pour éliminer les dépendances inter-couches qui ralentissaient les livraisons.
Cross-Functional Team
Équipe possédant en son sein toutes les compétences nécessaires pour produire un Increment potentiellement livrable, sans dépendance externe à d'autres équipes spécialisées.
Lors de la transition, les nouvelles cross-functional teams ont connu une baisse temporaire de productivité correspondant à la phase de forming du modèle de Tuckman.
D
Daily Scrum
Événement timeboxé à 15 minutes, tenu chaque jour par l'équipe de développement, dont le but est la synchronisation du travail et l'adaptation du plan de Sprint — et non le reporting de statut à des parties prenantes externes.
Le Scrum Master a coaché le Product Owner pour qu'il cesse d'assister au Daily Scrum en tant que destinataire de rapports individuels, rétablissant ainsi l'objectif de synchronisation de l'équipe.
Definition of Done (DoD)
Liste formelle de critères qu'un Increment doit satisfaire pour être considéré comme terminé, garantissant la transparence sur la qualité réelle du travail livré et guidant l'équipe dans ses estimations de Sprint Planning.
L'équipe a refusé de retirer les tests de régression de la Definition of Done car cela aurait introduit une dette technique et rendu l'Increment non potentiellement livrable.
E
Empiricism
Fondement philosophique de Scrum selon lequel la connaissance provient de l'expérience réelle et des observations, s'appuyant sur trois piliers : transparence, inspection et adaptation, pour gérer la complexité.
Steven a rappelé au Product Owner que l'empirisme rend impossible une prévision parfaite : de nouveaux apprentissages en cours de Sprint modifient naturellement le Sprint Backlog.
H
Hardening Sprint
Sprint non conforme à Scrum, ajouté en fin de cycle pour intégrer et stabiliser le travail des Sprints précédents, révélant que l'équipe n'a pas produit d'Increments potentiellement livrables tout au long du projet.
La demande d'un Hardening Sprint par l'équipe signalait une Definition of Done insuffisante et une accumulation de dette technique sur plusieurs Sprints.
I
Increment
Somme de tous les éléments du Product Backlog complétés pendant un Sprint et tous les Sprints précédents, devant être intégrée, potentiellement livrable et conforme à la Definition of Done à la fin de chaque Sprint.
Dans un contexte de Scrum à l'échelle, chaque équipe doit contribuer à un Increment unique et intégré plutôt que de maintenir des branches de code séparées.
P
Potentially Shippable Increment
Caractéristique requise de tout Increment Scrum : il doit être dans un état suffisamment qualitatif et intégré pour pouvoir être livré en production à tout moment, indépendamment de la décision commerciale de le déployer ou non.
L'équipe a reconnu que ses Increments n'étaient pas potentially shippable faute d'avoir complété les tests d'intégration, et a réestimé le travail nécessaire pour atteindre cet état.
Product Backlog
Liste ordonnée et émergente de tout le travail connu nécessaire au produit, gérée par le Product Owner ; dans un contexte multi-équipes, un seul Product Backlog existe pour un seul produit.
Le Scrum Master a conseillé de maintenir un unique Product Backlog partagé pour les trois équipes travaillant sur le même produit, afin d'éviter la fragmentation de la vision.
Product Owner
Rôle Scrum unique et accountable de la maximisation de la valeur du produit et de la gestion du Product Backlog ; dans un contexte multi-produits ou multi-équipes, un Product Owner distinct par produit est requis.
Le Product Owner a été coaché par le Scrum Master pour arrêter d'assister au Daily Scrum comme récepteur de rapports et se concentrer sur la priorisation du Product Backlog.
S
Scaled Scrum
Configuration dans laquelle plusieurs Scrum Teams travaillent sur un même produit à partir d'un seul Product Backlog, tout en restant conformes au Scrum Guide et en produisant un Increment intégré à chaque Sprint.
Dans leur déploiement de Scaled Scrum, les cinq équipes ont établi une Definition of Done partagée pour garantir l'intégration de leurs Increments dès le premier Sprint.
Self-Organization
Capacité de l'équipe de développement à décider de manière autonome comment accomplir son travail, résoudre ses conflits internes et s'adapter sans directive externe, dans les limites définies par Scrum (timeboxes, Increment potentiellement livrable).
Le Scrum Master a facilité une discussion entre les trois équipes pour qu'elles trouvent elles-mêmes une solution au partage de Dan, le spécialiste base de données, incarnant ainsi le principe de self-organization.
Servant Leadership
Style de leadership du Scrum Master qui consiste à servir l'équipe et l'organisation en facilitant les événements Scrum, en coachant sur l'empirisme, et en supprimant les impediments, plutôt qu'en dirigeant ou en prenant des décisions à la place de l'équipe.
Steven a démontré son servant leadership en facilitant la résolution du conflit sur la Definition of Done par l'ensemble de l'équipe Scrum plutôt qu'en imposant une décision.
Sprint Backlog
Ensemble des éléments du Product Backlog sélectionnés pour le Sprint, augmenté d'un plan pour livrer l'Increment et atteindre le Sprint Goal ; il appartient exclusivement à l'équipe de développement.
L'équipe de développement a adapté son Sprint Backlog en cours de Sprint après avoir découvert que les tests d'intégration nécessitaient plus d'effort que prévu.
Sprint Goal
Objectif unique et cohérent fixé pour le Sprint, donnant une direction à l'équipe de développement et une flexibilité quant aux fonctionnalités exactes à implémenter ; son absence souvent révèle un Product Backlog mal ordonné ou un Product Owner sans vision.
L'incapacité de l'équipe à formuler un Sprint Goal après douze Sprints signalait un manque d'objectifs produit clairs de la part du Product Owner.
Sprint Planning
Événement timeboxé en début de Sprint où l'équipe Scrum détermine le Sprint Goal, sélectionne les éléments du Product Backlog à réaliser et crée le Sprint Backlog, en s'appuyant sur la Definition of Done pour estimer la faisabilité.
Lors du Sprint Planning, l'équipe s'est appuyée sur l'objectif business du Product Owner pour sélectionner un sous-ensemble d'items réalisables malgré des exigences encore floues.
Sprint Retrospective
Événement formel de fin de Sprint permettant à l'équipe Scrum d'inspecter son fonctionnement (personnes, relations, processus, outils) et de définir des améliorations concrètes pour le Sprint suivant.
Steven a utilisé la Sprint Retrospective pour aider le Product Owner et l'équipe de développement à comprendre les causes profondes des changements constants affectant leur relation.
Sprint Review
Événement formel en fin de Sprint où l'équipe Scrum présente l'Increment aux parties prenantes pour obtenir des feedbacks et adapter le Product Backlog ; c'est l'occasion principale d'inspection de la valeur livrée.
La frustration des sponsors à la huitième Sprint Review résultait de leur absence aux reviews précédentes et d'un manque de transparence de la part du Product Owner.
T
Technical Debt
Conséquence de raccourcis techniques ou d'une Definition of Done affaiblie, créant une instabilité croissante du système, réduisant la vélocité future et générant de fausses hypothèses sur l'état réel de l'Increment.
Le Product Owner a voulu réduire la Definition of Done pour accélérer les livraisons, mais le Scrum Master a expliqué que la dette technique introduite ralentirait imprévisiblement les développements futurs.
Timebox
Contrainte de durée maximale fixe appliquée à chaque événement Scrum (ex. : 15 minutes pour le Daily Scrum, 4 heures pour le Sprint Planning d'un Sprint de deux semaines), favorisant la focalisation et l'auto-organisation.
Le Scrum Master a rappelé à l'équipe distribuée que réduire la fréquence du Daily Scrum violait le principe du timebox et réduisait la transparence sur les impediments.
Transparency
Premier pilier de l'empirisme Scrum exigeant que les aspects significatifs du processus soient visibles et compréhensibles par tous les responsables des résultats, notamment via les artefacts Scrum et les événements.
Le manque de transparence du Scrum Master et du Product Owner sur l'avancement réel a conduit les parties prenantes à découvrir lors de la huitième Sprint Review que le produit ne correspondait pas à leurs attentes.
V
Velocity
Mesure de la quantité de travail 'Done' complétée par une équipe lors d'un Sprint, utilisée uniquement comme outil de prévision interne à l'équipe et non comme indicateur de performance comparatif entre équipes.
Le Scrum Master a expliqué au directeur que la vélocité ne pouvait pas être imposée à la hausse de 15 % sur demande, car elle reflète la capacité réelle de l'équipe et sert au forecasting, pas à la mesure de performance.