PSM I : Pourquoi c'est plus dur que vous pensez

PSM I n’est pas difficile.

• Elle est sélective : Elle ne teste pas si tu connais Scrum.

• Elle teste si tu te trompes. Et la majorité des candidats se trompent… pour toujours les mêmes raisons.

  👉 Ce qui fait échouer :

  • penser “logique projet”

  • répondre trop vite

  • confondre pratique terrain et Scrum réel

1. PSM I est‑elle difficile ?

Sur le papier, oui : 80 questions en 60 minutes, 85% de bonnes réponses, beaucoup de formulations piégeuses. De nombreux candidats échouent à 1 ou 2 questions près, non parce qu’ils ne connaissent pas Scrum, mais parce qu’ils lisent trop vite ou qu’ils répondent “comme dans leur entreprise” plutôt que comme dans le Scrum Guide.

En réalité, la difficulté vient de deux choses :

• l’examen teste ta fidélité au Scrum Guide et aux principes d’empirisme (transparence, inspection, adaptation, auto‑organisation) ;

• il traque les réflexes de cycle en V et de project management classique (plan figé, chef de projet qui décide de tout).

Si tu acceptes de te recaler sur ce cadre, PSM I n’est plus un mur, mais un challenge très gérable.

2. Ce que PSM I mesure vraiment

Plutôt que des définitions récitées, PSM I évalue trois blocs de compétences.

a) Comprendre les rôles et qui décide quoi

• Product Owner : porte la valeur, définit le Product Goal, ordonne le Product Backlog et dit non quand c’est nécessaire.
  Réflexe PSM : l’ordre du Product Backlog appartient toujours au PO, même s’il écoute les autres.

• Scrum Master : responsable de l’efficacité de la Scrum Team, garant du cadre, coach et facilitateur.
  Réflexe PSM : dès que le Scrum Master ressemble à un chef de projet (assignation des tâches, gestion du plan détaillé, évaluation individuelle), la réponse est presque toujours fausse.

• Developers : construisent l’Incrément Done, s’auto‑organisent, gèrent le Sprint Backlog.
  Réflexe PSM : ce sont eux qui créent et ajustent le Sprint Backlog ; ni le PO ni le SM ne l’“approuvent”.

  👉 Si tu hésites sur “qui décide” → tu perds des points

b) Maîtriser les artefacts pour rendre le travail transparent

• Product Backlog + Product Goal : liste ordonnée, évolutive, alignée sur un cap.
  Réflexe PSM : un backlog figé sans Product Goal ressemble à un cahier des charges, pas à Scrum.

• Sprint Backlog + Sprint Goal : plan du Sprint, propriété des Developers, ajusté au quotidien.
  Réflexe PSM : le Sprint Goal est un objectif unique, pas une liste de stories ; on adapte le plan, jamais la durée du Sprint ni le niveau de qualité.

• Incrément + Definition of Done : somme de tout ce qui est Done, potentiellement livrable.
  Réflexe PSM : “presque fini” ne compte ni dans l’Incrément ni dans la vélocité ; on n’allège pas la DoD pour caser plus de travail.

  👉 Si ce n’est pas transparent → ce n’est pas Scrum

c) Utiliser les événements comme leviers d’inspection/adaptation

• Sprint & Sprint Planning : un conteneur d’un mois maximum, jamais prolongé ; un Planning qui répond à “pourquoi ? quoi ? comment ?”.
  Réflexe PSM : on ne met pas un Sprint en pause, on ne change pas son objectif en cours de route.​

• Daily Scrum : 15 minutes pour les Developers, centrées sur le Sprint Goal et le plan des 24 heures.​​
  Réflexe PSM : ce n’est pas un reporting au Scrum Master.

• Sprint Review : inspection de l’Incrément avec les parties prenantes, adaptation du Product Backlog.
  Réflexe PSM : ni recette, ni optionnel, même si l’Incrément est maigre.

• Sprint Retrospective : amélioration du système de travail, avec 1–2 actions concrètes pour le Sprint suivant.
  Réflexe PSM : fusionner Review et Retro ou considérer la Retro comme facultative est contraire au Guide.

  👉 Si ça devient du reporting → c’est faux

3. Les 10 vrais pièges qui font échouer PSM I

👉 90% des erreurs viennent de ces pièges

1. Lire trop vite : tu manques un “toujours”, “jamais”, “au plus”, “le plus approprié”.

2. Penser “chef de projet” : prolonger le Sprint, assigner les tâches, gérer un plan détaillé.

3. Mélanger les responsabilités PO / SM / Dev : ordre du Product Backlog, création du Sprint Backlog, annulation d’un Sprint.

4. Réduire les événements à du reporting : Daily de statut, Review‑recette, Retro qu’on zappe.

5. Toucher aux timeboxes : Sprint prolongé, événements fusionnés, “Sprint en pause”.

6. Sous‑estimer la DoD : compter le “presque fini”, baisser la DoD, multiplier les DoD pour un même produit.​​

7. Confondre artefacts et outils/métriques : vélocité, burn‑down, Jira ≠ artefacts Scrum.

8. Figurer le Sprint Backlog : croire qu’il ne peut plus changer après le Planning.

9. Bachoter les QCM sans le Scrum Guide : tu es perdu dès que la formulation change.

10. Répondre “comme chez toi” : choisir ce que fait ton entreprise plutôt que ce que dit le Guide.

👉 Si tu les identifies immédiatement → tu passes PSM I

4. Comment te préparer intelligemment à PSM I

👉 Lire ne suffit pas
👉 Comprendre ne suffit pas

=> Tu dois t’entraîner à éliminer les mauvaises réponse

1. Ancrer le Scrum Guide

   • Lis le Guide plusieurs fois (idéalement en anglais), crayon en main.

   • Pour chaque paragraphe, note à quel bloc il se rattache (rôle, artefact, événement) et ce qu’il interdit implicitement.

2. Consolider tes compétences Scrum

   • Entraîne‑toi à expliquer, à voix haute, les rôles, artefacts et événements avec tes mots, sans le texte sous les yeux.

   • Vérifie que tu peux dire “ce qui serait anti‑Scrum” pour chacun (Daily reporting, PO absent, etc.).

3. Utiliser les mocks pour entraîner ton “réflexe PSM”

   • Passe des examens blancs en conditions réelles (80 questions / 60 minutes).

   • Pour chaque erreur, retourne au Scrum Guide et rattache la bonne réponse au passage exact.

4. Répondre comme Scrum.org, pas comme ton organisation

   • Au moment de cocher, pose‑toi toujours les deux questions :

     1. De quoi parle‑t‑on : rôle, artefact, événement ?

     2. La proposition renforce‑t‑elle empirisme, transparence, auto‑organisation et qualité ?

Si la réponse est non, même si “c’est comme ça chez toi”, ce n’est probablement pas ce qu’attend PSM I.

👉 Le PSM n’est pas un examen de connaissance. C’est un examen de discernement.

Si tu veux réussir PSM I :

• tu ne dois pas apprendre Scrum

• tu dois apprendre à repérer les erreurs

  Et c’est exactement ce que tu travailles dans mes guides :

  • questions pièges

  • logique Scrum.org

  • scénarios réels

  👉 Accès direct sur le site et sur Amazon.

Disponibles dès maintenant sur ce site en version PDF et sur Amazon (version brochée et Kindle)