A
Artifact (Scrum Artifact)
L'un des trois éléments de transparence définis par Scrum : le Product Backlog, le Sprint Backlog et l'Increment. Chaque artefact est associé à un engagement formel qui renforce la transparence et la focalisation.
Lors d'un audit Scrum, l'équipe vérifie que les trois artefacts sont visibles et à jour avant chaque Sprint Review.
D
Definition of Done (DoD)
Engagement formel associé à l'Increment qui définit les critères de qualité minimaux que tout Increment doit respecter pour être considéré comme terminé. Elle est créée par les Developers et peut être influencée par les standards organisationnels.
La DoD de l'équipe stipule que tout code doit être revu, testé et déployé en environnement de staging avant d'être considéré comme Done.
Definition of Ready (DoR)
Pratique optionnelle, non prescrite par le Scrum Guide, qui définit le niveau de clarté suffisant qu'un Product Backlog Item doit atteindre avant d'être sélectionnable en Sprint Planning. Son usage est laissé à la discrétion de l'équipe.
L'équipe a adopté une DoR informelle exigeant qu'un PBI soit accompagné de critères d'acceptation avant d'entrer dans un Sprint, bien que le Scrum Guide ne le rende pas obligatoire.
Developers
L'un des trois rôles officiels du Scrum Team, responsable de créer un Increment utilisable à chaque Sprint. Les Developers décident du 'comment' technique, sélectionnent les PBIs en Sprint Planning et possèdent le Sprint Backlog.
Lors du Sprint Planning, les Developers évaluent leur capacité et sélectionnent eux-mêmes le nombre de PBIs qu'ils s'engagent à réaliser.
E
EBM (Evidence-Based Management)
Cadre empirique complémentaire à Scrum permettant au Product Owner de mesurer la valeur produit via des métriques d'impact business (ex. taux de conversion, rétention) plutôt que par des indicateurs de production comme la vélocité.
Le PO utilise l'EBM pour justifier la priorisation d'une fonctionnalité en présentant son impact attendu sur le taux de rétention des utilisateurs.
I
Increment
Artefact Scrum représentant la somme de tout le travail complété et conforme à la Definition of Done à la fin d'un Sprint. Un Increment doit être utilisable et potentiellement livrable, que le Product Owner décide ou non de le déployer.
À la fin du Sprint, l'Increment inclut les fonctionnalités des Sprints précédents et les nouvelles, toutes conformes à la DoD.
P
PBI (Product Backlog Item)
Unité de travail figurant dans le Product Backlog, pouvant représenter une fonctionnalité, une correction de bug, une amélioration technique, un spike ou un risque. Les PBIs sont ordonnés par le Product Owner selon la valeur.
Le PO a ordonné un PBI de correction de bug critique en tête du Product Backlog en raison de son impact direct sur la valeur utilisateur.
Product Backlog
Artefact Scrum unique et exhaustif listant tout ce qui pourrait être nécessaire pour améliorer le produit. Il est la propriété et la responsabilité du Product Owner, qui en assure l'ordonnancement et la transparence. Son engagement associé est le Product Goal.
Même avec quatre Scrum Teams travaillant sur le même produit, un seul Product Backlog est maintenu afin de garantir la cohérence des priorités.
Product Goal
Engagement formel associé au Product Backlog décrivant l'état futur à long terme du produit que le Scrum Team cherche à atteindre. Il sert d'objectif directeur pour tous les Sprints et peut évoluer en fonction des apprentissages.
L'équipe oriente chaque Sprint de façon à progresser vers le Product Goal, qui vise à atteindre 100 000 utilisateurs actifs mensuels d'ici six mois.
Product Owner (PO)
Rôle officiel unique (une seule personne, pas un comité) au sein du Scrum Team, responsable de maximiser la valeur du produit en gérant et en ordonnant le Product Backlog. Il détient l'autorité exclusive d'annuler un Sprint et d'inviter les parties prenantes à la Sprint Review.
Le PO a décidé d'annuler le Sprint en cours car le Sprint Goal est devenu obsolète suite à un changement de stratégie organisationnelle majeur.
R
Refinement (Product Backlog Refinement)
Activité continue (non un événement Scrum formel) au cours de laquelle le Product Owner et les Developers clarifient, décomposent et estiment les PBIs afin de les préparer pour les prochains Sprints. Le PO reste seul responsable de l'ordonnancement final.
Durant la semaine, le PO et les Developers ont consacré deux heures au refinement pour décomposer les epics en PBIs suffisamment clairs pour le prochain Sprint Planning.
S
Scrum Master
Rôle officiel du Scrum Team accountable de l'efficacité de l'équipe en facilitant les événements Scrum, en supprimant les impediments et en coachant l'équipe sur l'auto-organisation. Il facilite mais ne possède ni le Product Backlog ni le Sprint Backlog.
Le Scrum Master a facilité la Sprint Retrospective et a aidé l'équipe à identifier un processus de déploiement manuel comme impediment majeur à supprimer.
Sprint
Conteneur temporel fixe et immuable de maximum quatre semaines durant lequel le Scrum Team crée au moins un Increment utilisable. La durée d'un Sprint ne peut pas être modifiée en cours de Sprint ; elle ne peut être ajustée qu'entre deux Sprints.
L'équipe a constaté que des Sprints de deux semaines étaient trop courts pour livrer de la valeur et a décidé de passer à trois semaines lors du prochain Sprint.
Sprint Backlog
Artefact Scrum appartenant exclusivement aux Developers, composé du Sprint Goal, des PBIs sélectionnés et du plan d'action pour les réaliser. Il est vivant et peut être enrichi par les Developers dès qu'un nouveau besoin est identifié pour atteindre le Sprint Goal.
En cours de Sprint, les Developers ont ajouté une tâche technique au Sprint Backlog après avoir découvert une dépendance nécessaire pour atteindre le Sprint Goal.
Sprint Goal
Engagement unique et collaboratif du Sprint Backlog, créé par l'ensemble du Scrum Team lors du Sprint Planning. Il représente l'objectif cohérent du Sprint et offre de la flexibilité sur le scope précis des PBIs tout en maintenant une direction claire.
Le Sprint Goal 'permettre aux utilisateurs de finaliser leur inscription en autonomie' a guidé les Developers dans la négociation du scope lorsqu'un PBI s'est révélé plus complexe que prévu.
Sprint Planning
Événement Scrum timeboxé à 8 heures maximum pour un Sprint d'un mois, réunissant l'ensemble du Scrum Team pour définir le Sprint Goal et sélectionner les PBIs. Le PO clarifie les priorités et propose le Sprint Goal ; les Developers décident seuls de la quantité de travail qu'ils peuvent s'engager à réaliser.
Lors du Sprint Planning, le PO a présenté les trois PBIs les plus prioritaires, mais les Developers ont estimé ne pouvoir en prendre que deux au vu de leur capacité réelle.
Sprint Retrospective
Événement Scrum clôturant chaque Sprint, focalisé sur l'amélioration des processus, des personnes et des outils de l'équipe (et non sur le produit). Il est facilité par le Scrum Master ; le PO peut y participer mais n'en définit pas le contenu.
Lors de la Sprint Retrospective, l'équipe a décidé d'introduire des revues de code systématiques pour réduire le nombre de bugs détectés en fin de Sprint.
Sprint Review
Événement Scrum d'inspection et d'adaptation tenu à la fin du Sprint, au cours duquel le Scrum Team présente l'Increment aux parties prenantes invitées par le PO. Son output principal est un Product Backlog adapté, et non un simple rapport de statut.
Lors de la Sprint Review, les retours des parties prenantes sur la nouvelle interface ont conduit le PO à réordonner plusieurs PBIs dans le Product Backlog.
Stakeholder
Toute partie prenante externe au Scrum Team (clients, utilisateurs, managers, partenaires) dont les besoins et retours influencent le Product Backlog. Le PO est responsable de les engager activement, notamment en les invitant à la Sprint Review.
Le PO a invité le directeur commercial et deux clients clés à la Sprint Review afin de recueillir des retours directs sur les nouvelles fonctionnalités livrées.
T
Timebox
Durée maximale fixe allouée à un événement Scrum, qui ne peut pas être prolongée. Chaque événement Scrum (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) est timeboxé pour favoriser la discipline et l'efficacité.
Le Scrum Master a rappelé à l'équipe que le Daily Scrum est timeboxé à 15 minutes et qu'il fallait déplacer les discussions détaillées en dehors de cet événement.
V
Velocity
Métrique descriptive mesurant la quantité de travail complétée par un Scrum Team lors d'un Sprint, utilisée comme outil de planification capacitaire. La vélocité ne mesure pas la valeur produit et ne peut pas être imposée comme cible par le Product Owner.
Le PO souhaitait augmenter la vélocité pour livrer plus vite, mais le Scrum Master a rappelé que forcer les Developers à dépasser leur capacité violerait le principe de rythme soutenable.