10 mythes Scrum qui vous font perdre des points à l'examen

Les mythes Scrum qui font perdre le plus de points aux examens PSM I, PSPO I et CSM sont des habitudes qui ressemblent à du Scrum mais ne figurent pas dans le Scrum Guide 2020 : story points, vélocité, Sprint 0, règle des 10 % pour le raffinement, ou Scrum Master qui dirige l'équipe. Les questions d'examen Scrum sont écrites à partir du Guide ; une réponse fondée sur la façon dont votre entreprise applique Scrum est donc souvent le piège. Voici dix mythes, l'énoncé correct pour chacun et la raison pour laquelle les examinateurs s'en servent.

Pourquoi les questions d'examen Scrum reposent sur des mythes

Le Scrum Guide 2020 ne fait qu'environ 13 pages ; les auteurs d'examen ne peuvent donc pas vous interroger sur des détails obscurs. Ils testent plutôt votre capacité à distinguer le cadre de travail des pratiques que l'on ajoute par-dessus.

La pression du temps aggrave les choses. Vous avez peu de temps par question, et une option à la formulation familière est tentante quand le chronomètre tourne.

Une règle pratique : si le Scrum Guide ne le dit pas, ce n'est pas un élément obligatoire de Scrum.

10 mythes Scrum et ce que dit réellement le Scrum Guide

Mythe : les story points, la vélocité et les user stories font partie de Scrum

Réalité : le Scrum Guide ne mentionne ni les user stories, ni les story points, ni la vélocité, ni les burndown charts. Ce sont des pratiques complémentaires que beaucoup d'équipes utilisent, mais Scrum exige seulement un Product Backlog avec des éléments, un Sprint Backlog et des Increments qui respectent la Definition of Done.

Pourquoi c'est un piège : ces termes sont si courants au travail qu'ils semblent officiels. Méfiez-vous d'options comme "the Scrum Master tracks velocity" ou "items must be written as user stories". Si une réponse rend obligatoire une pratique complémentaire, elle est presque toujours fausse.

Mythe : le Scrum Master est le manager ou le chef de projet de l'équipe

Réalité : le Scrum Master est responsable de l'efficacité de la Scrum Team. La Scrum Team est une seule équipe, sans sous-équipes ni hiérarchies, et le Guide ne décrit aucun chef de projet ni chef d'équipe en son sein.

Pourquoi c'est un piège : les questions décrivent souvent un problème (un conflit, une échéance manquée, une tâche bloquée) et proposent une option où le Scrum Master attribue le travail ou décide à la place de l'équipe. La meilleure réponse montre généralement le Scrum Master en train de coacher, d'enseigner ou de lever un obstacle pour que l'équipe puisse résoudre le problème.

Mythe : le Daily Scrum est une réunion de suivi pour le Scrum Master et le Product Owner

Réalité : le Daily Scrum est un événement de 15 minutes pour les Developers, tenu à la même heure et au même endroit chaque jour ouvré du Sprint. Son but est d'inspecter les progrès vers le Sprint Goal et d'adapter le Sprint Backlog. Le Guide n'exige pas la présence du Product Owner, et le Scrum Master ne l'anime pas comme une séance de reporting.

Pourquoi c'est un piège : beaucoup de gens n'ont connu que des réunions quotidiennes où chacun rend compte à un responsable. Des options comme "the Product Owner must attend to approve the plan" ou "the Scrum Master collects status updates" visent cette expérience.

Mythe : le raffinement du Product Backlog prend 10 % de la capacité des Developers

Réalité : le raffinement est une activité continue, pas un événement, et le Scrum Guide 2020 ne donne aucun pourcentage. L'ancienne formulation « généralement pas plus de 10 % » a été supprimée en 2020.

Pourquoi c'est un piège : les anciens supports de révision et les anciennes questions d'entraînement citent encore le chiffre de 10 % ; dans un examen actuel, il n'y a aucun chiffre fixe.

Mythe : la Sprint Review est le moment où le Product Owner accepte ou livre le travail

Réalité : la Sprint Review est une séance de travail où la Scrum Team et les stakeholders inspectent le résultat du Sprint et décident de la suite. Ce n'est pas une porte de validation de mise en production. Un Increment naît lorsqu'un élément du Product Backlog respecte la Definition of Done, et les Increments peuvent être livrés aux stakeholders avant la Sprint Review.

Pourquoi c'est un piège : « démo et validation » est la manière dont beaucoup d'organisations conduisent la revue. À l'examen, toute option qui traite la Sprint Review comme le seul moment de livrer, ou comme une réunion d'approbation formelle, est suspecte.

Mythe : les équipes ont besoin d'un Sprint 0 ou d'un Sprint de consolidation

Réalité : le Scrum Guide ne mentionne ni Sprint 0 ni Sprint de consolidation (hardening). Chaque Sprint est censé produire au moins un Increment utile qui respecte la Definition of Done. Un Sprint consacré à la mise en place ou à la stabilisation du travail précédent laisse penser que la Definition of Done n'est pas respectée.

Pourquoi c'est un piège : ces noms sont très répandus, si bien qu'une question peut demander « que doit-il se passer pendant le Sprint 0 ? » comme s'il s'agissait d'une notion réelle. La bonne réponse ramène généralement à la livraison d'un Increment Done à chaque Sprint.

Mythe : le Product Owner peut être un comité

Réalité : le Product Owner est une seule personne, pas un comité. Le Product Owner peut représenter les besoins de nombreux stakeholders et déléguer du travail sur le Product Backlog à d'autres, mais reste responsable de la maximisation de la valeur et de la gestion du Product Backlog.

Pourquoi c'est un piège : c'est un grand classique du PSPO I. Repérez les options où un comité de pilotage ou plusieurs responsables métier se partagent la responsabilité du Product Owner ; le Guide ne le permet pas.

Mythe : le travail non terminé peut être montré à la Sprint Review

Réalité : le travail qui ne respecte pas la Definition of Done ne fait pas partie de l'Increment. Il retourne dans le Product Backlog pour être reconsidéré plus tard, et il ne peut être ni livré ni présenté à la Sprint Review.

Pourquoi c'est un piège : « le montrer quand même pour que les stakeholders donnent leur avis » semble raisonnable et collaboratif. À l'examen, c'est faux, car cela masque l'état réel du produit et rompt la transparence.

Mythe : le Sprint Backlog est figé une fois le Sprint Planning terminé

Réalité : le Sprint Backlog appartient aux Developers, qui sont responsables du plan et l'adaptent chaque jour à mesure qu'ils apprennent. Ce qui reste fixe, c'est l'engagement : le Sprint Goal, l'objectif unique du Sprint.

Pourquoi c'est un piège : les questions mélangent le Sprint Goal et le Sprint Backlog. Si une option dit que rien ne peut être ajouté ou modifié après la planification, ou que seul le Scrum Master peut mettre à jour le Sprint Backlog, elle est fausse.

Mythe : les équipes sont « auto-organisées » et le Scrum Master est un « servant-leader »

Réalité : le Guide 2020 dit que les Scrum Teams sont autogérées : elles décident en interne qui fait quoi, quand et comment. Il décrit les Scrum Masters comme de « vrais leaders qui servent la Scrum Team et l'organisation au sens large », en remplacement du terme « servant-leader » de 2017. Il parle aussi de responsabilités plutôt que de rôles.

Pourquoi c'est un piège : l'ancienne formulation n'est pas fausse dans l'esprit, mais les questions qui demandent ce que dit le Guide actuel récompensent les termes actuels. Si deux options se ressemblent, choisissez celle qui emploie le vocabulaire de 2020.

Comment s'entraîner à repérer ces pièges

1. Lisez deux fois le Scrum Guide. Une première lecture d'une traite pour la vue d'ensemble, puis une seconde lentement, en repérant chaque responsabilité, chaque engagement (Product Goal, Sprint Goal, Definition of Done) et chaque timebox.
2. Tenez une liste de mots déclencheurs. Des mots comme doit, toujours, approuver, attribuer, rendre compte ou un pourcentage fixe sont souvent associés à la mauvaise option. Vérifiez si le Guide le dit réellement.
3. Entraînez-vous sous pression de temps. Connaître la réponse à votre bureau n'est pas la même chose que la trouver en moins d'une minute. Essayez un examen blanc PSM chronométré gratuit sur Scrumdemy (20 questions, 20 minutes) ou l'examen blanc CSM gratuit.
4. Étudiez les explications, pas seulement le score. Pour chaque mauvaise réponse, retrouvez dans le Guide la phrase qui tranche. Si vous préparez le PSPO I, le quiz de préparation PSPO I de Scrumdemy propose une explication pour chacune de ses 80 questions.
5. Ajoutez les tests gratuits officiels. Les Open Assessments de Scrum.org (Scrum Open, Product Owner Open, Developer Open) sont gratuits et rédigés dans le style du vrai examen.

FAQ

Les story points font-ils partie de Scrum ?

Non. Le Scrum Guide 2020 ne mentionne ni les story points, ni la vélocité, ni les user stories. Ce sont des pratiques facultatives ; une réponse d'examen qui les rend obligatoires est donc fausse.

Le Product Owner doit-il assister au Daily Scrum ?

Non. Le Daily Scrum est un événement de 15 minutes pour que les Developers inspectent les progrès vers le Sprint Goal. Le Guide n'exige pas la présence du Product Owner.

« Servant-leader » est-il encore la bonne réponse au PSM I ?

Le Guide 2020 a remplacé « servant-leader » par « vrais leaders qui servent la Scrum Team et l'organisation au sens large ». Quand une question demande ce que dit le Guide actuel, choisissez la formulation de 2020.

Le travail inachevé peut-il être présenté à la Sprint Review ?

Non. Le travail qui ne respecte pas la Definition of Done retourne dans le Product Backlog et ne peut être ni présenté à la Sprint Review ni livré.