QCM

Notion : Création et livraison des Increments pendant un Sprint.
Explication : Un Sprint peut produire plusieurs Increments utilisables. Leur mise à disposition peut intervenir avant la fin du Sprint : il n'est pas nécessaire d'attendre la Revue pour apporter de la valeur. Les réponses correctes se complètent donc : elles distinguent le nombre d'Increments possibles, le moment de leur livraison et le rôle de la Revue.
À retenir : La Revue de Sprint n'est pas une porte obligatoire avant toute livraison.
Piège fréquent : Confondre la Revue avec une autorisation de mise à disposition et retenir systématiquement les Increments jusqu'à cet événement.

Notion : Différence entre Revue et Rétrospective de Sprint.
Explication : La Revue examine le résultat du Sprint, notamment l'Increment, ainsi que le contexte du produit. Cette inspection permet d'adapter le Product Backlog si nécessaire. La Rétrospective examine plutôt la manière de travailler : personnes, interactions, processus et outils, afin de définir des améliorations. Les bonnes réponses se complètent en précisant l'objet de chaque inspection et les adaptations recherchées.
À retenir : La Revue concerne le produit ; la Rétrospective concerne le fonctionnement de l'équipe.
Piège fréquent : Présenter la Rétrospective comme une séance d'acceptation ou de refus de l'Increment.

Notion : Le Product Backlog Refinement comme activité continue.
Explication : Le refinement consiste à préciser les éléments du Product Backlog, notamment leur description, leur ordre et leur taille. Il ne constitue pas un événement Scrum séparé doté d'une durée fixe. Les deux réponses correctes se complètent : l'une définit la nature continue de l'activité, l'autre explique le travail réalisé. Une réunion peut servir cette activité, sans devenir pour autant une obligation hebdomadaire de deux heures.
À retenir : Affiner le backlog est une activité, pas un événement supplémentaire imposé.
Piège fréquent : Inventer une fréquence obligatoire ou réserver cette activité au seul Scrum Master.

Notion : La limite de temps du Sprint Planning.
Explication : Pour un Sprint d'un mois, le Sprint Planning est limité à huit heures. Pour un Sprint plus court, sa durée est généralement plus courte. Cette limite représente un maximum, et non une durée à remplir. Pour un Sprint de deux semaines, les faits fournis ne permettent donc pas de considérer six heures comme une obligation ni de calculer une durée exacte par simple proportion.
À retenir : Adapter la durée à la longueur du Sprint ne signifie pas imposer toute la durée disponible.
Piège fréquent : Transformer un plafond en quota obligatoire, ou croire que le Scrum Master peut prolonger l'événement au-delà de sa limite.

Notion : La Definition of Done comme référence de qualité.
Explication : La Definition of Done décrit formellement l'état d'un Increment qui satisfait les mesures de qualité requises. Les éléments qui ne la respectent pas ne font pas partie de l'Increment. L'abaisser pour afficher davantage de fonctionnalités terminées dégrade la transparence de la qualité. Les bonnes réponses relient ainsi la visibilité de la qualité à la composition réelle de l'Increment.
À retenir : Une prévision ne justifie pas de réduire les exigences de qualité.
Piège fréquent : Croire qu'une dérogation temporaire ou une déclaration du Product Owner suffit à rendre terminé un élément non conforme.

Notion : Taille du Scrum Team et efficacité collective.
Explication : Un Scrum Team est généralement composé de dix personnes ou moins pour rester agile et communiquer efficacement. Avec douze développeurs et des difficultés de communication, il faut examiner l'effet de la taille sur la communication et l'auto-gestion. Une réorganisation en plusieurs équipes cohérentes peut être envisagée, avec un même Product Goal, un même Product Backlog et un même Product Owner.
À retenir : Examiner la taille et envisager une organisation cohérente sont deux démarches complémentaires.
Piège fréquent : Chercher une solution automatique en multipliant les Scrum Masters ou imposer des Product Owners différents pour un même produit.

Notion : Délégation du travail et responsabilité du Product Owner.
Explication : Le Product Owner peut demander de l'aide et déléguer des travaux liés au Product Backlog, comme la rédaction ou l'ordre des éléments. Il reste néanmoins responsable de sa gestion efficace, de la communication de sa finalité et de la maximisation de la valeur. Les réponses correctes se complètent : elles distinguent l'exécution des tâches de la responsabilité conservée sur le résultat.
À retenir : Déléguer une tâche ne transfère pas la responsabilité du Product Owner.
Piège fréquent : Supposer que le Scrum Master devient responsable du backlog, ou interdire toute aide au Product Owner.

Notion : Distinguer fréquence de livraison et valeur créée.
Explication : Livrer fréquemment favorise l'apprentissage, mais ne démontre pas à lui seul que le produit apporte de la valeur. Les retours des utilisateurs et les résultats d'usage permettent d'inspecter les effets obtenus et le contexte, puis d'adapter le produit et le Product Backlog selon les preuves disponibles. Les bonnes réponses associent donc une limite de la livraison fréquente au moyen de mieux apprécier ses résultats.
À retenir : Livrer est une activité ; comprendre son impact nourrit l'inspection et l'adaptation.
Piège fréquent : Assimiler le nombre de fonctionnalités au succès, ou considérer la mesure d'impact comme incompatible avec Scrum.

Notion : Les cinq valeurs Scrum.
Explication : Scrum repose sur l'engagement, le focus, l'ouverture, le respect et le courage. Ces valeurs donnent une direction aux comportements de l'équipe. Pour distinguer les bonnes réponses, il faut reconnaître chaque valeur de cette liste, y compris lorsque deux d'entre elles sont regroupées dans une même proposition. Les réponses correctes se complètent pour couvrir les cinq valeurs, sans ajouter d'autres notions.
À retenir : Mémorisez l'ensemble : engagement, focus, ouverture, respect, courage.
Piège fréquent : Confondre des attentes comme le contrôle ou la prévisibilité avec les valeurs officiellement énoncées de Scrum.

Notion : Traitement durable des obstacles récurrents.
Explication : Le Scrum Master aide l'équipe et l'organisation à éliminer les obstacles et à progresser. Lorsqu'un obstacle revient à chaque Sprint, un contournement temporaire ne traite pas sa cause. Le rendre transparent permet de rechercher une cause systémique ; faciliter une action durable vise ensuite à améliorer la capacité de l'équipe. Ces deux démarches se complètent : comprendre le problème puis agir sur ce qui l'entretient.
À retenir : Un obstacle récurrent mérite un traitement de fond, pas seulement un contournement.
Piège fréquent : Masquer le problème pour préserver les indicateurs ou désigner automatiquement un développeur comme responsable.