J’ai passé le PSPO I : retour sur ma préparation

Passer le PSPO I, ou Professional Scrum Product Owner I, était pour moi une façon de structurer une expérience déjà acquise en produit. Je connaissais les réunions Scrum, la gestion d’un backlog et les échanges avec les équipes de développement, mais je voulais vérifier que mes pratiques correspondaient réellement au cadre Scrum. Cette certification m’a surtout obligé à clarifier le rôle du Product Owner et la valeur de chaque décision prise au quotidien.

Pourquoi viser le PSPO I ?

Le PSPO I est une évaluation proposée par Scrum.org. Elle valide la compréhension des responsabilités du Product Owner, de la maximisation de la valeur et du fonctionnement empirique de Scrum. Ce n’est pas une certification qui transforme instantanément quelqu’un en Product Owner opérationnel : elle vérifie plutôt la capacité à comprendre les principes, les responsabilités et les conséquences de ses choix.

Mon objectif était double : obtenir une validation reconnue par l’industrie et identifier mes zones de fragilité. Dans un parcours de montée en compétences, cette étape est utile parce qu’elle vient après les fondamentaux, sans remplacer l’expérience terrain. J’ai donc abordé la préparation comme un parcours progressif, et non comme une simple mémorisation de définitions.

Ma méthode de préparation

1. Revenir au Scrum Guide

J’ai commencé par lire plusieurs fois le Scrum Guide, lentement, en prenant des notes. La difficulté ne vient pas du vocabulaire, relativement court, mais de la précision des formulations. Les rôles, les événements et les artefacts sont liés par un système de responsabilités ; il est risqué de les apprendre comme une liste indépendante.

Pour chaque passage important, je me suis posé trois questions : quelle est l’intention ? qui porte la responsabilité ? que se passe-t-il si cette responsabilité est mal comprise ? Cette approche m’a aidé à dépasser les raccourcis fréquents, notamment l’idée que le Product Owner serait simplement la personne qui rédige les user stories.

2. Relier la théorie aux situations concrètes

J’ai ensuite repris des situations vécues : backlog trop volumineux, demandes contradictoires de parties prenantes, pression pour ajouter une fonctionnalité en cours de Sprint ou difficulté à définir un objectif de produit. Pour chacune, j’ai cherché la réponse la plus cohérente avec Scrum, plutôt que celle qui semblait la plus confortable à court terme.

Ce travail m’a permis de mieux distinguer le rôle du Product Owner de celui d’un chef de projet traditionnel. Le Product Owner est responsable de la maximisation de la valeur et de la gestion efficace du Product Backlog. Il ne décide pas seul de la manière technique de construire l’incrément et ne peut pas déléguer sa responsabilité, même s’il peut déléguer certaines activités.

3. Utiliser les tests avec discernement

Les tests d’entraînement ont été utiles pour repérer les sujets à revoir. Je les ai toutefois utilisés après la lecture des ressources, jamais comme unique méthode. Répondre correctement à une question sans comprendre le raisonnement derrière la réponse donne une fausse impression de préparation.

• Je notais chaque erreur dans un tableau de suivi.
• Je regroupais les erreurs par thème : valeur, backlog, événements ou empirisme.
• Je reformulais ensuite la règle avec mes propres mots.
• Je revenais au Scrum Guide pour vérifier la source.

Cette logique de préparation m’a rappelé qu’une progression efficace ne dépend pas uniquement du nombre d’heures consacrées à une certification. Dans d’autres domaines du quotidien, on retrouve la même nécessité de comparer les options, de vérifier les contraintes et d’avancer étape par étape : choisir une fleur vivace longue floraison demande par exemple de tenir compte de l’exposition, du sol et de l’usage prévu. La méthode compte autant que la décision finale.

Les difficultés rencontrées

La première difficulté a été de résister aux intuitions issues des organisations classiques. Certaines pratiques paraissent raisonnables, comme demander au Product Owner de valider chaque détail technique ou considérer le Sprint Review comme une simple démonstration. Pourtant, Scrum insiste sur l’inspection, l’adaptation et la collaboration avec les parties prenantes.

La deuxième difficulté concernait les formulations ambiguës. Certaines questions semblent avoir plusieurs réponses acceptables si l’on raisonne avec ses habitudes professionnelles. Il faut alors revenir au cadre : quelle option protège le mieux la transparence ? laquelle favorise l’inspection ? laquelle permet réellement d’adapter le produit ou le plan ?

Enfin, j’ai dû travailler la gestion du temps. L’évaluation comporte de nombreuses questions à traiter dans un temps limité. Je me suis entraîné à répondre d’abord aux questions certaines, puis à revenir sur celles qui nécessitaient davantage de réflexion. Cette stratégie évite de perdre plusieurs minutes sur un seul énoncé.

Le jour de l’évaluation

Le jour venu, j’ai relu mes notes synthétiques, sans tenter d’absorber de nouveaux sujets. J’ai installé un environnement calme et vérifié ma connexion avant de commencer. Pendant l’évaluation, j’ai lu chaque question jusqu’au bout, en portant une attention particulière aux mots comme « toujours », « uniquement » ou « nécessairement ».

Une fois terminé, le résultat a confirmé que la préparation avait été suffisante. Mais le principal bénéfice est venu du travail effectué en amont : je comprends désormais mieux pourquoi certaines pratiques d’équipe créent de la valeur et pourquoi d’autres réduisent l’autonomie ou la transparence.

Mes conseils pour réussir le PSPO I

• Lisez le Scrum Guide plusieurs fois et prenez au sérieux chaque formulation.
• Ne confondez pas expérience professionnelle et compréhension du cadre Scrum.
• Reliez chaque notion à une situation produit concrète.
• Utilisez les tests blancs pour apprendre, pas seulement pour mesurer un score.
• Révisez les responsabilités du Product Owner, la valeur, le Product Goal et le Product Backlog.
• Le jour J, lisez précisément les questions et gardez un rythme régulier.

Un jalon, pas une finalité

Le PSPO I constitue un bon jalon pour formaliser des connaissances et donner de la crédibilité à un projet d’évolution vers le produit. Il ne remplace ni la pratique, ni l’observation d’une équipe, ni la capacité à dialoguer avec les utilisateurs et les développeurs.

Pour la suite, je souhaite approfondir la discovery, la mesure de la valeur et la stratégie produit. Une certification est vraiment utile lorsqu’elle s’inscrit dans une trajectoire : apprendre les fondamentaux, expérimenter, recueillir du feedback, puis valider officiellement ses compétences. Pour comparer d’autres parcours et certifications, consultez notre page d’accueil.