Les 10 pièges les plus fréquents aux examens Scrum

Après avoir rédigé des centaines de questions d'entraînement, un constat revient : les candidats échouent rarement par manque de lecture. Ils échouent parce qu'ils répondent avec des réflexes de management traditionnel. Voici les dix pièges les plus coûteux.

1. Croire que le Scrum Master dirige l'équipe

Le Scrum Master n'assigne pas les tâches, ne valide pas le travail et n'arbitre pas les décisions techniques. Il est responsable de l'efficacité de l'équipe, pas de son commandement. Toute réponse où il « décide à la place de » est presque toujours fausse. La frontière avec le Product Owner mérite un guide à elle seule : qui décide quoi, vraiment.

2. Penser que le Sprint peut être prolongé

Jamais. La durée d'un Sprint est fixe. Si le travail n'est pas terminé, il retourne au Product Backlog. Un Sprint ne s'allonge pas, ne se raccourcit pas.

3. Confondre Sprint Goal et liste d'éléments

Le Sprint Goal est l'engagement ; les éléments sélectionnés sont une prévision. On peut renégocier le périmètre en cours de Sprint sans toucher au Goal. Terminer tous les éléments sans atteindre le Goal n'est pas une réussite. Le sujet mérite un guide à lui seul : Product Goal et Sprint Goal.

4. Croire que la Sprint Review est une démo

C'est une séance de travail collaborative où l'on inspecte le résultat et où l'on adapte le Product Backlog. Ce n'est ni une présentation à sens unique, ni une validation formelle de livraison.

5. Attendre la Sprint Review pour livrer

Un Increment peut être livré à tout moment du Sprint, dès qu'il satisfait la Definition of Done. La Review n'est pas une barrière à la livraison de valeur.

6. Baisser la qualité sous la pression

La qualité ne diminue pas et la Definition of Done ne s'assouplit pas pour « finir à temps ». Un travail qui ne satisfait pas la DoD n'est tout simplement pas un Increment.

7. Prévoir un « Sprint 0 » ou une semaine de stabilisation

Scrum ne connaît ni l'un ni l'autre. Dès le premier Sprint, l'équipe vise un Increment utilisable. Un besoin récurrent de stabilisation révèle une Definition of Done trop faible. Le piège revient sans cesse au PSD I, où l'absence d'architecte et de phase préalable est l'un des points les plus testés.

8. Multiplier les Product Owners ou les backlogs

Un produit = un Product Backlog et un Product Owner, même avec plusieurs équipes. Le Product Owner est une personne, pas un comité.

9. Transformer le Daily Scrum en rapport d'avancement

Le Daily appartient aux Developers : il sert à inspecter la progression vers le Sprint Goal et à adapter leur plan. Ce n'est pas un point de contrôle pour le Product Owner ou le management.

10. Répondre « ce qui marche en vrai » plutôt que ce que dit Scrum

C'est le piège le plus subtil. L'examen évalue votre compréhension du cadre Scrum, pas les compromis de votre organisation actuelle. Si votre entreprise fait autrement, cela ne rend pas sa pratique correcte au sens de l'examen.

Comment s'en prémunir

Pour chaque question situationnelle, testez la réponse contre trois critères : préserve-t-elle l'auto-gestion de l'équipe ? Maintient-elle la transparence ? Protège-t-elle le Sprint Goal ? Une réponse qui coche les trois est presque toujours la bonne.

Ce réflexe se travaille en conditions réelles plutôt qu'en lecture. La méthode en quatre étapes pour le PSM I décrit le rythme de préparation qui le fait tenir le jour J.