QCM

Notion : La valeur du résultat et l'inspection en Revue de Sprint.
Explication : Terminer les éléments prévus montre que le travail planifié a été réalisé, mais ne démontre pas que le besoin utilisateur est satisfait. La Revue permet d'inspecter le résultat par rapport à l'Objectif du Produit et d'adapter le Product Backlog. Les deux réponses se complètent : constater l'écart de valeur, puis orienter la suite.
À retenir : Respecter un plan ne garantit pas de créer la valeur attendue.
Piège fréquent : Confondre achèvement et pertinence, exiger une acceptation automatique ou reporter la vérification à la fin du produit.

Notion : La responsabilité de l'ordre du Product Backlog.
Explication : Le Product Owner reste responsable de la gestion efficace et de l'ordre du Product Backlog, même lorsqu'un développeur intervient à sa demande. Les développeurs décident comment transformer les éléments sélectionnés en Increment. Le Product Backlog peut évoluer pendant le Sprint, mais une modification ne doit pas compromettre l'Objectif du Sprint. Les bonnes réponses associent donc responsabilité et protection de l'objectif.
À retenir : Faire évoluer les priorités ne transfère pas la responsabilité du Product Owner.
Piège fréquent : Donner cette responsabilité aux développeurs ou croire que tout changement est interdit pendant un Sprint.

Notion : L'adaptation du périmètre pendant un Sprint.
Explication : Une exigence nouvelle, même critique, ne doit pas être ajoutée automatiquement. Les développeurs et le Product Owner peuvent clarifier et renégocier le périmètre en préservant l'Objectif du Sprint. Les bonnes réponses se complètent : discuter de l'ajustement et vérifier sa compatibilité avec l'objectif. Si cet objectif devient obsolète, seul le Product Owner peut annuler le Sprint.
À retenir : Adapter le travail est possible ; protéger l'objectif reste essentiel.
Piège fréquent : Confondre urgence et ajout obligatoire, ou considérer toute nouvelle demande comme un motif systématique d'annulation.

Notion : L'utilisabilité de l'Increment et la Definition of Done.
Explication : Un travail techniquement achevé ne constitue pas nécessairement un Increment. Il doit satisfaire la Definition of Done et être utilisable. Si une dépendance non intégrée empêche l'utilisation attendue, les critères locaux de qualité ne suffisent pas pour déclarer le résultat terminé. Les bonnes réponses relient ainsi la condition concrète d'utilisabilité à l'engagement de qualité.
À retenir : Une dépendance bloquante empêche de considérer le travail comme un Increment conforme.
Piège fréquent : Assimiler finition technique et résultat utilisable, ou croire qu'une promesse d'intégration future suffit.

Notion : La vélocité comme indicateur contextuel de prévision.
Explication : La vélocité peut aider à prévoir du travail dans un contexte donné, mais elle ne mesure pas directement la valeur produite. Transformée en quota, elle peut inciter à optimiser le chiffre au détriment de la qualité et de la valeur. Les bonnes réponses se complètent : elles signalent le risque d'utilisation abusive et la limite de comparaison entre contextes.
À retenir : La vélocité aide à prévoir ; elle n'est ni une mesure obligatoire de Scrum ni un objectif de performance.
Piège fréquent : Croire qu'augmenter les estimations améliore réellement le produit.

Notion : Le Daily Scrum comme inspection et adaptation par les développeurs.
Explication : Le Daily Scrum sert aux développeurs à inspecter leur progression vers l'Objectif du Sprint et à adapter leur plan de travail. Il ne vise pas à rendre compte individuellement au Scrum Master. Les bonnes réponses associent le diagnostic et l'action : examiner la progression, puis ajuster le plan pendant l'événement ou immédiatement après.
À retenir : Le Daily Scrum est centré sur l'objectif et le travail collectif, pas sur le contrôle des personnes.
Piège fréquent : Le transformer en interrogatoire à ordre fixe ou en suivi de l'activité individuelle.

Notion : La collaboration et les responsabilités en planification du Sprint.
Explication : L'absence du Product Owner peut priver les développeurs d'échanges nécessaires pour comprendre la valeur et le contexte des éléments. Leur prévision risque alors d'être moins pertinente. Ils restent responsables de la prévision et du plan, sans reprendre la responsabilité du Product Owner de maximiser la valeur du produit. Les bonnes réponses distinguent donc l'effet de l'absence et le maintien des responsabilités.
À retenir : Une collaboration insuffisante fragilise la planification sans transférer les responsabilités.
Piège fréquent : Faire choisir les éléments par le Scrum Master ou déclarer automatiquement le Sprint illégitime.

Notion : Les liens entre transparence, inspection et adaptation.
Explication : Cacher les défauts compromet directement la transparence : l'état réel du produit n'est plus visible. L'inspection de l'Increment devient alors trompeuse, et les adaptations s'appuient sur des informations incomplètes ou fausses. Les trois bonnes réponses décrivent cette chaîne : rendre visible permet d'inspecter correctement, puis d'adapter sur une base fiable.
À retenir : Sans transparence, l'inspection et l'adaptation perdent leur fiabilité.
Piège fréquent : Protéger un indicateur de réussite en masquant la réalité, ou présenter la vélocité comme un engagement contractuel de Scrum.

Notion : La distinction entre Objectif du Sprint et Definition of Done.
Explication : L'Objectif du Sprint donne une direction au travail, mais son atteinte ne remplace pas les conditions nécessaires pour produire un Increment utilisable. La Definition of Done est l'engagement associé à l'Increment : elle définit les exigences à satisfaire pour le considérer comme terminé. Les bonnes réponses se complètent en distinguant l'objectif atteint de la conformité du résultat.
À retenir : Atteindre l'objectif ne dispense jamais de satisfaire la Definition of Done.
Piège fréquent : Déclarer terminé un résultat inutilisable ou réduire la Definition of Done à la documentation finale.

Notion : L'accompagnement organisationnel par le Scrum Master.
Explication : Face à des validations externes imposées, le Scrum Master aide à rendre visibles leurs effets sur le flux de travail et la valeur. Il facilite aussi la compréhension et l'adoption de Scrum par l'organisation. Ces actions se complètent : comprendre les conséquences des contraintes permet d'accompagner leur traitement et de favoriser l'autonomie de l'équipe.
À retenir : Le Scrum Master aide à comprendre et à traiter les obstacles, sans remplacer les responsables.
Piège fréquent : Supprimer arbitrairement les validations ou devenir un chef de projet qui distribue les tâches.