Anyone looking into Scrum certifications today quickly runs into the question: CSM (Scrum Alliance) or PSM (Scrum.org)? The usual comparisons then list prices, exam formats, and renewal fees. That information is correct, but it misses the most important question.
The most important question is: what should be different at the end? A certificate on your resume, or a real improvement in your ability to work in an actual organization, with real people, in an agile way?
I (Anton here) have been delivering Scrum trainings for over 10 years, and let me be upfront about where I stand: I am a Certified Scrum Trainer with the Scrum Alliance, and my trainings lead to the CSM and CSPO certifications. So I have a stake in this. That is exactly why I want to be fair here, including toward the other model.
The fair objection: “CSM is just attendance”
Anyone who researches this finds that criticism quickly, and it deserves an honest answer: the CSM exam is considerably easier than the PSM I exam. That is true. The PSM I exam is demanding, tightly timed, and tests the terms and rules of the Scrum Guide precisely. Anyone who passes it on their own and without AI has truly absorbed the Scrum Guide. That is an achievement, and I know excellent Scrum Masters with a PSM certificate.
But the reverse conclusion, that a harder exam means a better education, is a fallacy. The two certifications test different things because they are built differently:
With PSM, the exam is the central element. Training is optional, and many prepare through self-study. Quality assurance rests on the exam, so the exam has to be hard.
With CSM, the training is the central element. It is mandatory, lasts at least two full days, and may only be delivered by trainers who have passed a multi-year selection process and demonstrated years of Scrum experience beforehand. Quality assurance rests on the training; the exam afterward essentially confirms that the basics have landed.
So you are not comparing two exams. You are comparing two models: tested knowledge versus lived learning. Which model is better depends on what you want to achieve.
Why “experiencing it” is not a platitude in Scrum
There is a moment I observe in almost every training, and one I had myself many years ago in my own first training. Most people arrive with a quiet conviction: “Scrum, agility, those are buzzwords for things I have known for ages. We already have meetings and work in a team.”
This conviction cannot be cleared up with definitions. You can memorize the Scrum Guide and still hold on to it. It dissolves only when you experience the way of working yourself: in a simulation where your own team fails at the very same points it fails at in real projects, and then discovers how differently it runs when the principles are actually applied. In that moment, something happens that no multiple-choice test can measure: participants connect the principles to their own successes and failures from their working reality. Afterward, they have a reference experience.
A concrete example of this is the feedback loops in the simulations. When people experience how short but real feedback on the effectiveness of their work leads to a challenging conversation, and then, in the next loop, to genuinely better results, they suddenly understand what is going wrong with their Sprint Review or their demo meeting at work. The fix is often not easy. But now they have a gut feeling for how it should feel, and that feeling is informed by a real experience, not by a definition.
A second experience reinforces this, and it is one a trainer can hardly create alone: in the room sit people from different organizations. When someone hears that an element of Scrum which supposedly “doesn’t work here” at their own company is completely self-evident at another organization, they begin to seriously question their own processes. These many independent experiences of others help people abstract away from their own organization, and that abstraction is a necessary precondition for anyone to actually change their own ways of working. A trainer’s opinion alone often cannot achieve this.
This reference experience is the difference between “I can explain what a Sprint is” and “I can see in my own company why our so-called Sprint isn’t one, and I know where to start.” The first gets you through a test. The second makes you effective.
Learning terms or understanding principles
A training designed to prepare you for a hard multiple-choice test inevitably optimizes for what the test can measure: terms, rules, distinctions. That is not worthless; precise knowledge of terminology has its place. But Scrum is not a set of rules you follow. It is a framework built on empirical principles: transparency, inspection, adaptation. Someone who only knows the rules applies them mechanically and wonders why it doesn’t work. Someone who has understood the principles can also decide in situations that appear in no guide, and that is what makes up ninety percent of a Scrum Master’s or Product Owner’s day.
How large this difference is shows in one of the most common misunderstandings of all: confusing acceptance criteria, that is, the description of individual Product Backlog items, with the Definition of Done. The distinction is hard to retain by memorizing. But once you experience, across two full days, how both are used continuously side by side, you understand the difference immediately and develop a gut feeling here too, one that rarely emerges from self-study.
It is the same with retrospectives. In my trainings, we hold retrospectives about the training itself. There, participants experience the difference between a vague goal (“We want to stay more focused on the topics tomorrow”) and a concrete, verifiable measure (“When we lose focus, we hold up this card”). That sounds trivial, but it is a key learning moment: anyone who is later meant to guide a team toward effective self-improvement as a Scrum Master needs not only to know this difference but to have felt it.
How to recognize a good training, regardless of the certificate
To be fair: there are experience-oriented PSM trainings, and there are CSM trainings that fall short of their potential. The certificate logo alone guarantees nothing. So ask the provider these questions:
- How much time do participants spend in simulations and exercises, and how much with slides? A good training is well above half active time. If a trainer works without a projector and PowerPoint, that further increases focus on the content.
- How much practical experience does the trainer have in agile teams, beyond training? A good trainer has worked in various roles and many different contexts, and shares experiences from them.
- Is there room for disagreement and discussion in the training, or is the material simply pushed through?
- Which elements of Scrum are applied directly to running the training itself? Only through experience do you develop an intuition for applying them correctly.
Which path fits whom
If you already work in a well-functioning Scrum team and have done so for years, and you need a formal certificate, the PSM path with self-study is a legitimate, cost-effective option. You already have your reference experience; the exam confirms your knowledge.
But if you are new to the role, growing into it, or if, like most people, you work in an organization where “Scrum” has so far been more of a label, then experience is what you need, not the test. In that case you should choose a training where you can experience the way of working, question it, and connect it to your own reality, and the certificate is the side effect, not the goal.