QCM

Notion : L'annulation d'un Sprint lorsque son Objectif devient obsolète.
Explication : Seul le Product Owner dispose du pouvoir d'annuler le Sprint. L'obsolescence de l'Objectif justifie cette décision : poursuivre le travail ne servirait plus l'objectif initial. L'annulation n'efface pas les résultats obtenus. Le travail terminé est revu et les éléments conformes à la Definition of Done peuvent constituer un Increment. Les éléments non terminés sont réestimés et remis dans le Product Backlog.
À retenir : Autorité du Product Owner, pertinence de l'Objectif et conformité du travail terminé sont trois aspects complémentaires.
Piège fréquent : Confondre un retard avec un motif d'annulation décidé par le Scrum Master, ou croire que le travail restant est détruit.

Notion : La capacité cross-fonctionnelle d'une équipe Scrum.
Explication : Une équipe doit pouvoir produire un Increment complet. Si chaque fonctionnalité dépend d'une autre équipe pour être testée, cette dépendance limite sa capacité à terminer son travail. Il faut donc examiner les compétences disponibles, la Definition of Done et les éventuels silos organisationnels. Développer les compétences nécessaires en interne répond à la cause du problème plutôt qu'à ses seuls symptômes.
À retenir : Identifier la dépendance et renforcer les capacités de l'équipe sont deux démarches complémentaires pour obtenir un Increment complet.
Piège fréquent : Présenter le transfert permanent vers une équipe de test comme la meilleure solution, ou allonger simplement le Sprint sans traiter la dépendance.

Notion : L'intégration de la qualité au travail du Sprint.
Explication : Reporter systématiquement les tests automatisés à la fin du projet retarde la validation du travail. L'équipe risque alors de considérer comme terminés des éléments qui ne satisfont pas la Definition of Done. Ce décalage masque aussi la qualité réelle de l'Increment : sans validation, les décisions reposent sur une vision incomplète. La qualité doit être intégrée au travail, et non reportée dans une phase finale séparée.
À retenir : Conformité et transparence se complètent : valider le travail permet de savoir réellement ce qui est terminé.
Piège fréquent : Exclure les tests pour préserver le périmètre, ou considérer un Sprint de test séparé comme la solution systématique.

Notion : Les limites de la comparaison des vélocités entre équipes.
Explication : La vélocité dépend du contexte de chaque équipe, de ses estimations et de sa manière de découper le travail. Un chiffre supérieur ne démontre donc pas une meilleure performance ni davantage de valeur livrée. Récompenser l'équipe affichant le plus grand chiffre peut encourager le gonflement des estimations ou une dégradation de la qualité. Les deux objections se complètent : la comparaison est fragile et l'incitation peut modifier les comportements.
À retenir : La vélocité ne mesure pas directement la valeur du produit.
Piège fréquent : Chercher à augmenter les points plutôt qu'à améliorer le produit, comme si un nombre plus élevé prouvait un meilleur résultat.

Notion : La distinction entre activité réalisée et résultats obtenus.
Explication : Le nombre de tickets fermés indique un volume d'activité. À lui seul, il ne permet pas de connaître la qualité du travail, son impact utilisateur ou sa contribution à l'Objectif du Produit. En faire l'indicateur principal peut pousser l'équipe à privilégier de nombreux petits tickets plutôt que les travaux les plus utiles. Ces limites se complètent : l'indicateur décrit mal les résultats et peut orienter les comportements dans une mauvaise direction.
À retenir : Fermer davantage de tickets ne prouve pas que davantage de valeur a été créée.
Piège fréquent : Assimiler ce compteur à l'engagement du Sprint ou à une preuve automatique d'atteinte de l'Objectif du Produit.

Notion : La maximisation de la valeur sans sacrifier la qualité.
Explication : Accumuler des fonctionnalités ne garantit pas une augmentation de la valeur. Une qualité insuffisante peut réduire leur utilité et accroître les risques. Il faut rendre ces conséquences visibles pour éclairer les décisions du Product Owner. En parallèle, les éléments qui ne satisfont pas la Definition of Done ne doivent pas être acceptés dans l'Increment. Ces actions associent une décision produit informée à une exigence claire de conformité.
À retenir : La valeur se juge avec la qualité et le risque, pas seulement avec le volume livré.
Piège fréquent : Abaisser la Definition of Done pour afficher davantage de fonctionnalités, ou supposer qu'une fonctionnalité prime toujours sur la qualité.

Notion : La responsabilité des développeurs sur le Sprint Backlog.
Explication : Le Sprint Backlog est un plan établi par et pour les développeurs. Ils l'adaptent pendant le Sprint à mesure qu'ils apprennent. Une demande de changement peut être discutée avec le Product Owner pour clarifier ou renégocier le périmètre, sans mettre en danger l'Objectif du Sprint. Cette discussion ne donne pas à une partie prenante le pouvoir d'imposer directement des tâches.
À retenir : Le plan peut évoluer ; les développeurs le gèrent et le Product Owner participe aux discussions sur le périmètre.
Piège fréquent : Confondre adaptation avec intervention imposée de l'extérieur, ou croire que le Sprint Backlog doit rester figé malgré l'évolution du contexte.

Notion : Le refinement progressif face à l'incertitude.
Explication : Estimer très finement tout le Product Backlog avant les premiers apprentissages peut donner une illusion de certitude. Le détail des estimations ne supprime pas les inconnues et peut consommer du temps qui serait utile pour apprendre ou créer de la valeur. Le refinement permet d'ajouter progressivement les détails nécessaires en tenant compte des connaissances disponibles. Les deux risques sont liés : l'effort investi peut être important sans rendre les prévisions réellement plus fiables.
À retenir : Une estimation précise en apparence n'est pas une garantie de stabilité du périmètre.
Piège fréquent : Croire que Scrum exige une estimation complète avant le premier Sprint ou que le détail empêche les changements.

Notion : L'adaptation du Sprint face à un incident de production.
Explication : Un incident grave change le contexte et peut nécessiter une adaptation du plan. L'équipe doit discuter avec le Product Owner des conséquences sur le périmètre et évaluer si l'Objectif du Sprint reste pertinent. Ces démarches se complètent : l'une organise la réponse opérationnelle, l'autre vérifie que le Sprint conserve son sens. L'Objectif doit être protégé lorsqu'il reste pertinent ; son éventuelle obsolescence doit être reconnue.
À retenir : Un incident appelle une décision transparente et adaptée au contexte, pas une réaction automatique.
Piège fréquent : Ajouter le travail sans rendre ses conséquences visibles, ou annuler systématiquement le Sprint dès qu'un incident survient.

Notion : La distinction entre problème observé et solution validée.
Explication : Un retour ou un problème constitue un signal à comprendre, pas la preuve qu'une nouvelle fonctionnalité est nécessaire. Transformer immédiatement chaque observation en développement confond le diagnostic avec la solution. Cela peut aussi détourner l'équipe des priorités fondées sur la valeur et l'Objectif du Produit. L'inspection et l'adaptation demandent donc de comprendre le problème puis d'évaluer une réponse pertinente.
À retenir : Comprendre le besoin et prioriser la réponse sont deux étapes complémentaires ; ajouter une fonctionnalité n'est pas une conclusion automatique.
Piège fréquent : Croire que Scrum impose de convertir chaque retour en élément du Product Backlog ou que davantage de fonctionnalités signifie une meilleure adaptation.