QCM

Notion : La valeur d’un élément du Product Backlog ne se déduit pas de son niveau de détail technique.
Explication : Pour comprendre un élément, il faut identifier le problème utilisateur qu’il vise et le résultat attendu. Cette clarification avec le Product Owner permet ensuite d’évaluer sa contribution à l’Objectif du Produit. Les deux démarches se complètent : l’une précise le besoin, l’autre vérifie sa cohérence avec la direction du produit.
À retenir : Un élément bien spécifié doit aussi avoir une finalité comprise pour éclairer les décisions.
Piège fréquent : Confondre précision technique et valeur, puis lancer le développement uniquement parce que la spécification semble prête.

Notion : La transversalité des compétences et l’auto-gestion concernent l’équipe Scrum collectivement.
Explication : L’équipe doit disposer des compétences nécessaires pour créer de la valeur. Lorsque les spécialistes refusent toute intervention hors de leur domaine, les silos peuvent générer des dépendances et des files d’attente qui empêchent de produire un Increment. Ils réduisent aussi la capacité de l’équipe à organiser collectivement son travail. Ces risques se complètent : l’un touche le résultat, l’autre le fonctionnement collectif.
À retenir : La spécialisation ne doit pas empêcher la coopération.
Piège fréquent : Croire que Scrum impose des domaines étanches ou que l’attribution permanente des tâches par le Scrum Master résout les silos.

Notion : La Revue de Sprint soutient l’inspection et l’adaptation à partir des résultats observés.
Explication : Cette session de travail permet d’examiner l’Increment et le contexte pour discuter des adaptations utiles. Recueillir des idées de fonctionnalités sans examiner l’usage actuel laisse l’inspection insuffisante. Les adaptations du Product Backlog risquent alors de reposer davantage sur des opinions que sur des observations. Les deux constats sont liés : une inspection pauvre fournit une base moins solide aux décisions.
À retenir : Les propositions gagnent à être confrontées aux résultats et aux observations.
Piège fréquent : Réduire la Revue à une démonstration sans discussion ou exclure les parties prenantes.

Notion : La Definition of Done détermine si un travail peut faire partie de l’Increment.
Explication : Un élément presque terminé qui ne respecte pas cette définition n’est pas terminé. Il ne doit donc pas être inclus dans l’Increment ni comptabilisé comme valeur livrée. Il retourne au Product Backlog pour une nouvelle considération et une nouvelle priorisation. Ces actions se complètent : la première rend l’état du résultat transparent, la seconde permet de réexaminer le travail restant.
À retenir : « Presque terminé » ne signifie pas « Done ».
Piège fréquent : Assouplir le critère de finition pour préserver une prévision ou parce que le travail restant paraît faible.

Notion : L’Objectif du Produit et l’Objectif du Sprint orientent le travail à des horizons différents.
Explication : L’Objectif du Produit décrit une cible future du produit. L’Objectif du Sprint exprime le but et la valeur recherchés pendant le Sprint ; il aide les développeurs à guider leurs décisions au cours de celui-ci. Ces caractéristiques se complètent : la cible du produit donne une direction, tandis que le but du Sprint oriente le travail en cours.
À retenir : Distinguer la destination du produit du but du Sprint permet de comprendre leur rôle respectif.
Piège fréquent : Considérer les deux objectifs comme un seul et même engagement.

Notion : Le Product Owner est une personne, et non un comité.
Explication : La responsabilité de maximiser la valeur et de gérer efficacement le Product Backlog doit rester clairement attribuée à une seule personne. Les parties prenantes peuvent apporter des informations pour éclairer les décisions sans devenir un comité de décision concurrent. Ces deux principes se complètent : les contributions peuvent être multiples, mais la responsabilité reste unique.
À retenir : Multiplier les sources d’information ne signifie pas multiplier les Product Owners.
Piège fréquent : Croire que la complexité du produit exige deux Product Owners ou que le Scrum Master doit prendre ce second rôle pour accélérer les décisions.

Notion : Scrum repose sur l’empirisme et une approche lean, pas seulement sur la tenue d’événements.
Explication : La transparence rend les résultats et la situation suffisamment visibles pour permettre une inspection pertinente. Cette inspection doit ensuite conduire à une adaptation lorsque les observations ou le contexte l’exigent. Les deux principes se complètent : sans transparence, l’inspection est fragilisée ; sans adaptation nécessaire, les apprentissages ne modifient pas les décisions.
À retenir : Les événements servent à rendre possible la boucle transparence, inspection, adaptation.
Piège fréquent : Prendre la présence des événements pour une preuve suffisante de Scrum, tout en conservant un plan figé malgré les résultats observés.

Notion : Le Product Backlog est une liste émergente et ordonnée destinée à améliorer le produit.
Explication : Son contenu et son ordre peuvent évoluer à partir des apprentissages, notamment des retours utilisateurs. Le Product Owner reste responsable de sa gestion efficace. Ces deux aspects se complètent : l’évolution permet d’intégrer ce qui est appris, tandis qu’une responsabilité claire soutient la gestion de cette liste. L’affinement se fait au besoin, sans exiger un détail uniforme permanent.
À retenir : Un Product Backlog évolutif est conforme à Scrum.
Piège fréquent : Vouloir figer tous les éléments avant le premier Sprint ou maintenir chacun au même niveau de détail.

Notion : Le Sprint Backlog rassemble le but du Sprint, le travail sélectionné et le plan pour le réaliser.
Explication : Il contient l’Objectif du Sprint, les éléments du Product Backlog sélectionnés pour ce Sprint et un plan d’action permettant de produire l’Increment. Ces trois composantes se complètent : l’objectif indique le but, les éléments sélectionnés définissent le travail retenu et le plan explique comment le réaliser.
À retenir : Le Sprint Backlog ne se réduit ni à une liste d’éléments ni à un ensemble de tâches isolées.
Piège fréquent : Le considérer comme un contrat immuable imposé par le Product Owner, plutôt que comme un support de planification du Sprint.

Notion : L’Objectif du Sprint est le but unique qui donne une cohérence au Sprint.
Explication : Il est créé pendant le Sprint Planning et permet une certaine flexibilité sur le travail exact nécessaire pour l’atteindre. Ces caractéristiques se complètent : la planification établit le but commun, puis ce but sert de repère sans figer chaque tâche. Il faut donc distinguer ce que le Sprint cherche à accomplir des moyens précis employés pour y parvenir.
À retenir : Un but unique peut guider un travail dont les détails évoluent.
Piège fréquent : Transformer l’Objectif du Sprint en une liste exhaustive et immuable de tâches techniques.