QCM

Notion : La qualité technique d’un Increment et la valeur du produit sont deux aspects distincts.
Explication : Un Increment techniquement correct peut rester inutilisé s’il ne répond pas au besoin prioritaire. Il faut donc inspecter les usages, les comportements et les retours des utilisateurs, puis vérifier la pertinence du problème traité. Ces inspections se complètent : les premières montrent ce qui se passe réellement, la seconde aide à comprendre si le produit vise le bon besoin. Elles orientent l’adaptation du produit et du Product Backlog.
À retenir : La conformité technique ne démontre pas à elle seule la valeur.
Piège fréquent : Assimiler une code review réussie à une validation client, ou ajouter des fonctionnalités sans analyser la non-utilisation.

Notion : L’auto-gestion repose sur une organisation collective du travail, pas sur l’isolement individuel.
Explication : L’équipe décide en interne qui fait quoi, quand et comment. Une répartition initiale des tâches n’est donc pas problématique en soi ; c’est sa rigidité et le refus d’entraide qui créent des silos. Ceux-ci peuvent laisser des travaux bloqués ou inachevés, augmenter le travail en cours et réduire la capacité collective à atteindre l’Objectif du Sprint. Ces conséquences se complètent : la dégradation du flux fragilise le résultat commun.
À retenir : L’organisation du travail doit soutenir l’Objectif du Sprint.
Piège fréquent : Croire que la spécialisation garantit toujours un meilleur flux, ou que le Scrum Master doit attribuer les tâches.

Notion : La Sprint Retrospective sert à planifier des améliorations de la qualité et de l’efficacité.
Explication : Exprimer les difficultés ne suffit pas : l’équipe doit comprendre leurs causes et choisir quelques améliorations importantes, concrètes et applicables. Ces deux démarches se complètent. L’analyse des causes évite de traiter uniquement les symptômes ; la sélection d’actions transforme les constats en changements. Des améliorations peuvent être ajoutées au Sprint Backlog suivant afin d’être intégrées au travail de l’équipe.
À retenir : Une Rétrospective utile relie problèmes observés, causes et actions d’amélioration.
Piège fréquent : En faire un rapport individuel de performance ou cacher les problèmes pour préserver l’image de l’équipe.

Notion : L’ordre du Product Backlog doit soutenir la maximisation de la valeur.
Explication : La facilité de développement peut éclairer une décision, mais elle ne représente pas à elle seule la valeur d’un élément. Le Product Owner doit aussi considérer notamment les risques, les dépendances et les apprentissages attendus. Ainsi, un travail moins facile peut être pertinent s’il réduit une incertitude importante. Les critiques se complètent : elles montrent à la fois la limite du critère de facilité et l’intérêt d’autres critères pour orienter le produit.
À retenir : Développer le plus facile n’équivaut pas nécessairement à développer le plus utile.
Piège fréquent : Appliquer systématiquement ce critère ou transférer entièrement l’ordonnancement à l’équipe technique.

Notion : En contexte complexe, une prévision reste différente d’une garantie.
Explication : L’équipe peut prévoir une date et un périmètre à partir des informations disponibles, mais les apprentissages futurs peuvent modifier cette prévision. Une réponse solide associe donc une estimation à la transparence sur les hypothèses, les risques et l’incertitude. Ces éléments se complètent : la prévision aide à décider, tandis que la transparence permet d’en comprendre les limites et les adaptations possibles.
À retenir : L’empirisme suppose d’adapter les décisions aux informations nouvelles, pas de garantir un périmètre immuable.
Piège fréquent : Présenter la vélocité comme une garantie de date exacte ou prétendre que Scrum impose une promesse ferme à six mois.

Notion : Un prototype technique peut être un moyen d’apprentissage sans être automatiquement un Increment utilisable.
Explication : Son intérêt réside dans la réduction d’un risque ou d’une incertitude significative. Pour être pertinent, cet apprentissage doit contribuer à une décision ou à l’Objectif du Produit ou du Sprint. Les deux critères se complètent : réduire l’incertitude est utile lorsque cela éclaire effectivement le travail à réaliser. Le caractère expérimental du prototype ne suffit toutefois pas à démontrer qu’il constitue un Increment utilisable.
À retenir : Évaluer un prototype par l’apprentissage utile qu’il apporte, sans confondre exploration et résultat utilisable.
Piège fréquent : Considérer tout prototype comme un Increment ou comme une autorisation de contourner la Definition of Done.