Professional Scrum Master I (PSM I) looks deceptively easy and is not. It is built almost entirely on one short document, the official Scrum Guide, yet it carries an 85% pass mark and gives you only 60 minutes for 80 questions. People fail it not because Scrum is complicated but because they study how their own team happens to work rather than what the Guide actually says, and because they treat Scrum as a set of mechanics to memorise instead of a coherent framework with a reason behind every rule. This guide is a full self-study course built around that reality. It teaches the Scrum framework as the Guide defines it, explains the intent the harder questions hinge on, walks through the misconceptions that trip people up, and turns it all into a study and exam-day plan. It is original teaching material only. It contains no real or simulated exam questions, and the Scrum Guide is the authoritative source you should confirm everything against.
Chapter 1: Exam overview and how to use this guide
What PSM I actually measures
PSM I measures whether you understand the Scrum framework precisely and can act as a Scrum Master true to it, not whether you can describe Scrum loosely or recount your team’s habits. The exam is based on the current Scrum Guide (the 2020 edition), and its questions are written against the Guide’s exact definitions. That precision is the whole game. A question will often present an answer that sounds sensible and is how many real teams behave, alongside the answer the Guide actually prescribes, and you have to know the difference. This is why the most common cause of failure is “experience interference”: confident practitioners answer from their workplace, where Scrum is frequently bent, and lose marks they did not expect to lose.
The format and why the numbers matter
The exam is 80 multiple-choice, multiple-answer and true/false questions in 60 minutes, with a required score of 85%, which means at least 68 of 80 correct. It is taken online through Scrum.org, on demand, with no proctor and no booking, and once earned the certification never expires. Two of those numbers shape your whole preparation. The 85% pass mark leaves almost no room for error, so “mostly understanding” Scrum is not enough; you need the definitions cold. The 45 seconds per question average means there is no time to look anything up despite the exam being open-internet in practice; you must treat it as closed-book and know the material well enough to answer on sight.
How to use this course
Read the framework chapters in order, because Scrum’s pieces only make sense as a connected whole: the events exist to enable empiricism, the artifacts exist to create transparency, and the accountabilities exist to protect that system. For every element, do what the exam rewards and ask “why does Scrum include this?”, because the answer to that question is usually the answer to the hardest version of the test item. Treat the bold terms as definitions you must be able to state exactly. The later chapters cover the Scrum Master role in depth, the misconceptions that cause most failures, and a concrete plan that leans on Scrum.org’s free Open Assessments.
Chapter 2: Scrum theory - empiricism and the values
Everything in Scrum follows from its theory, so this is the right place to start and the part that makes the rest memorable rather than arbitrary.
Empiricism and lean thinking
Scrum is founded on empiricism: the idea that knowledge comes from experience and that decisions are made on the basis of what is observed, not on detailed up-front prediction. Empiricism is implemented through three pillars. Transparency means the work and the process are visible to those doing and receiving the work, because you cannot make good decisions about things you cannot see. Inspection means frequently checking progress and artifacts to detect problems. Adaptation means adjusting as soon as inspection shows you are off course. Scrum also rests on lean thinking, which reduces waste and focuses on the essentials. The reason this matters for the exam is that almost every event and artifact can be explained as serving transparency, inspection or adaptation, and questions about the purpose of an event are really questions about which pillar it serves.
The five Scrum values
Scrum defines five values: commitment, focus, openness, respect and courage. The team commits to achieving its goals and to supporting each other; it focuses on the work of the Sprint and the Product Goal; its members are open about the work and the challenges; they respect each other as capable, independent people; and they have the courage to do the right thing and to work on tough problems. These are not decorative. When inspection and adaptation are built on transparency, the values are what make transparency real, because a team that lacks openness or courage will hide problems and break empiricism. Expect questions where the best answer is the one that upholds a value, for example choosing openness about a missed forecast over concealing it.
Why theory is the foundation
The practical study lesson is to learn the framework downward from this theory rather than as a flat list of rules. If you understand that Scrum exists to run an empirical process safely, then the events become the cadence for inspection and adaptation, the artifacts become the things made transparent, and the values become the behaviours that keep it honest. Candidates who skip the theory and memorise the mechanics tend to fail the “why” questions; candidates who internalise empiricism can often reason out an answer they did not explicitly revise.
Chapter 3: The three accountabilities
The Scrum Team is a single team of people with no sub-teams or hierarchies, and it holds three accountabilities. The 2020 Scrum Guide deliberately calls these accountabilities rather than roles, to stress that they describe what each part of the team is responsible for, not job titles.
The Scrum Team and the Developers
The Scrum Team is typically ten or fewer people, small enough to stay nimble and large enough to do meaningful work, and it is cross-functional (it has all the skills needed) and self-managing (it decides who does what, how, and when). The Developers are the people committed to creating any aspect of a usable Increment each Sprint. They are accountable for creating a plan for the Sprint (the Sprint Backlog), instilling quality by adhering to the Definition of Done, adapting their plan each day toward the Sprint Goal, and holding each other accountable as professionals. “Developers” here means anyone doing the work, not only programmers.
The Product Owner
The Product Owner is accountable for maximising the value of the product resulting from the team’s work. They do this by developing and explicitly communicating the Product Goal, and by creating, ordering and clearly communicating the Product Backlog. The Product Owner is one person, not a committee, and although they may delegate the work of managing the backlog, they remain accountable for it. A crucial exam point is that for the Product Owner to succeed, the whole organisation must respect their decisions; no one tells the Developers to work from a different set of requirements, and changes to the backlog go through the Product Owner.
The Scrum Master
The Scrum Master is accountable for the team’s effectiveness and for establishing Scrum as defined in the Guide. They do this by helping the team and the organisation improve their practices within the framework. The Scrum Master is a true leader who serves the Scrum Team, the Product Owner and the wider organisation: coaching team members in self-management and cross-functionality, helping the team focus on creating high-value Increments, removing impediments, ensuring the Scrum events happen and are productive, and helping the organisation adopt Scrum. The single most tested misconception is that the Scrum Master is a project manager or a boss who assigns work and drives the team; they are not. They serve and enable, and the next chapters and Chapter 6 develop exactly what that means.
Chapter 4: The five events
Scrum uses a set of events to create regularity and to provide formal opportunities to inspect and adapt, replacing the need for other, ad hoc meetings. There are five, and the key insight is that the first one contains the other four.
The Sprint as the container
The Sprint is the heartbeat of Scrum and the container for all the other events. It is a fixed length of one month or less, and a new Sprint starts immediately after the previous one ends. During a Sprint, no changes are made that would endanger the Sprint Goal, quality does not decrease, the Product Backlog is refined as needed, and scope may be clarified and renegotiated with the Product Owner as more is learned. Sprints enable predictability by ensuring inspection and adaptation toward the Product Goal at least every calendar month. Only the Product Owner has the authority to cancel a Sprint, and that happens only if the Sprint Goal becomes obsolete.
Planning, the Daily Scrum, and the two reviews
Sprint Planning opens the Sprint and is timeboxed to a maximum of eight hours for a one-month Sprint. It addresses three topics: why the Sprint is valuable (the Sprint Goal), what can be done, and how the chosen work will get done; its output is the Sprint Backlog. The Daily Scrum is a 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog; it is theirs, and while others may attend, it is not a status meeting for management. The Sprint Review is timeboxed to a maximum of four hours for a one-month Sprint and is where the Scrum Team and stakeholders inspect the Increment and the product, and adapt the Product Backlog together; it is a working session, not just a demo.
The Sprint Retrospective
The Sprint Retrospective closes the Sprint and is timeboxed to a maximum of three hours for a one-month Sprint. The team inspects how the last Sprint went with regard to individuals, interactions, processes, tools and its Definition of Done, and identifies the most helpful changes to improve its effectiveness. The Retrospective is the dedicated engine of continuous improvement and a frequent exam topic. The unifying lesson across all five events is that each is a scheduled chance to inspect and adapt: planning sets direction, the Daily Scrum adapts the daily plan, the Review adapts the product, and the Retrospective adapts the team’s way of working. Note that timeboxes are maximums and shrink proportionally for shorter Sprints.
Chapter 5: The three artifacts and their commitments
Scrum’s artifacts represent work or value and are designed to maximise transparency. The 2020 Guide gave each artifact a commitment to reinforce empiricism and focus, and the pairing of artifact to commitment is one of the most reliably tested facts on the exam.
Product Backlog and the Product Goal
The Product Backlog is an emergent, ordered list of what is needed to improve the product, and it is the single source of work for the Scrum Team. Its commitment is the Product Goal, the long-term objective the team plans against; the Product Goal is in the Product Backlog, and the rest of the backlog emerges to define what will fulfil it. Refinement is the ongoing activity of breaking down and adding detail to backlog items, and the Developers who will do the work are responsible for sizing it.
Sprint Backlog and the Sprint Goal
The Sprint Backlog is composed of the Sprint Goal (the why), the set of Product Backlog items selected for the Sprint (the what), and an actionable plan for delivering the Increment (the how). It is a plan by and for the Developers, a real-time picture of the work they plan to accomplish during the Sprint, and they update it throughout as they learn. Its commitment is the Sprint Goal, the single objective for the Sprint that gives the team focus and coherence and is something they meet together rather than as a set of separate tasks.
Increment and the Definition of Done
The Increment is a concrete stepping stone toward the Product Goal; each Increment adds to prior ones and must be usable and verified to work. Multiple Increments may be created within a Sprint. Its commitment is the Definition of Done, a formal description of the state the Increment must reach to be considered complete and of release quality. Work that does not meet the Definition of Done cannot be released or even presented at the Sprint Review and returns to the Product Backlog. The exam tests this strictly: the Definition of Done creates transparency about what “done” really means, and “done” is not negotiable per item. Across all three artifacts the pattern to lock in is artifact-to-commitment: Product Backlog to Product Goal, Sprint Backlog to Sprint Goal, Increment to Definition of Done.
Chapter 6: The Scrum Master role and common misconceptions
Because the certification is specifically for the Scrum Master, the exam probes this accountability harder than any other, and it does so largely by testing whether you can tell genuine servant leadership apart from the command-and-control habits that creep into real workplaces.
Serving three audiences
The Scrum Master serves the Scrum Team by coaching it in self-management and cross-functionality and by helping it produce valuable Increments; serves the Product Owner by helping with backlog management, Product Goal definition and stakeholder collaboration; and serves the organisation by leading and coaching its Scrum adoption and removing barriers between stakeholders and teams. Seeing the role as service to three audiences, rather than as managing one team, is the frame the exam rewards. Notice that the Scrum Master has no authority over the people on the team; their influence comes from coaching, facilitation and removing impediments, not from assigning work or evaluating performance.
The misconceptions that cause most failures
A large share of wrong answers come from importing project-manager instincts. The Scrum Master does not assign tasks to Developers (the Developers self-manage and decide who does what), does not run the Daily Scrum as a status report (it belongs to the Developers), does not own or change the Product Backlog (that is the Product Owner), and does not decide how much work goes into a Sprint (the Developers select it). Equally, the Scrum Master is not a passive note-taker; serving the team is active work. Another set of traps concerns what Scrum prescribes versus what teams add: Scrum does not mandate a particular tool, a separate “Sprint zero”, story points, or a daily three-questions script, so answers that present optional team conventions as Scrum rules are usually wrong.
Reasoning from intent
The reliable way through these questions is to return to intent. When a scenario tempts you toward directing the team, ask whether the empirical, self-managing answer is available, because it usually is and usually wins. When a scenario describes a team bending a rule, ask which pillar, transparency, inspection or adaptation, the rule protects, and the Guide-faithful answer becomes clear. Studying the Scrum Master role is therefore less about memorising a job description and more about practising the judgement to choose service over control and the Guide over habit.
Chapter 7: Study plan and using the Open Assessments
PSM I rewards depth of understanding over hours logged, so the plan is short but demanding, and it is built around one free resource that mirrors the real exam closely: Scrum.org’s Open Assessments.
A focused multi-week plan
Two to four weeks of focused study is typical. In week one, read the Scrum Guide closely (twice is not too many) and concentrate on the theory: empiricism, the three pillars, and the five values, until you can explain why Scrum is empirical in your own words. In week two, work through the three accountabilities, the five events and the three artifacts with their commitments, connecting each one back to inspection and adaptation rather than memorising it in isolation. In week three, go deep on the Scrum Master role and the common misconceptions, and start drilling the Open Assessments. If you are new to Scrum, add a gentler fourth week to build familiarity before the drilling intensifies. Someone already working in Scrum can compress this to about a week, but should not skip the misconception work, since that is where experience most often misleads.
Drilling the Open Assessments to the mid-90s
The Scrum Open assessment on Scrum.org is free, unlimited, and drawn from the same body of understanding as the real exam, which makes it the best readiness gauge available. Take it repeatedly, under the time limit, until you are scoring in the mid-90s consistently, not just once. The reason to aim above the 85% bar is twofold: the real exam is broader and a little harder than the open assessment, and scoring high on the open version proves your answers are becoming instant, which is what the 45-seconds-per-question pace demands. Each time you miss an item, go back to the exact wording in the Scrum Guide rather than just noting the right letter, because the exam tests precise definitions and that is where the marks are. To turn this into dated study weeks for your own start date, use the free study-plan generator, and if you are weighing this against a broader project credential, the PMP vs PMI-ACP comparison and similar comparisons can help you place Scrum certification in context.
Chapter 8: Final preparation, exam day, and format
Final preparation
In your last few days, stop reading new material and instead drill the Open Assessments and re-read the Scrum Guide one more time with fresh eyes, paying special attention to the artifact-commitment pairings, the event timeboxes, and the Scrum Master’s boundaries. The single most valuable mental shift before the exam is to commit to answering what the Scrum Guide says rather than what your team does, because the gap between the two is the most common reason capable practitioners fail. If a definition still feels fuzzy, fix it now; at 85% you cannot afford several soft spots.
Manage the clock
Eighty questions in sixty minutes is roughly 45 seconds each, so time, not difficulty, is the hidden challenge. Work a fast first pass that answers everything you know immediately and flags anything that needs thought, then spend the remaining minutes on the flagged items. Do not plan to look things up: even though the exam is open-internet in practice, searching mid-exam will drain your clock and is how people who “knew it” still fail. The reason you drilled the Open Assessments to the mid-90s is precisely so that at exam speed your answers are recalled, not worked out.
Exam day and format
The exam is taken online through Scrum.org, on demand, with no proctor and no scheduled booking, so you sit it when you are ready. It is 80 questions in 60 minutes requiring 85% (68 correct), and the certification does not expire once earned, with no renewal fees. Apply the discipline you practised: answer from the Guide, watch for plausible-but-wrong “how my team works” options, prefer the answer that upholds empiricism and the Scrum Master’s servant-leader boundaries, and keep moving so the clock never becomes the thing that beats you. Prepared this way, the exam’s reputation for being “harder than it looks” works in your favour, because the trap that catches most people is the one you will have spent your final week defusing.