Domain 1: Understanding and Applying the Scrum Framework
- Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and decisions are made on what is observed; lean thinking reduces waste and focuses on the essentials. This is why the framework is small and why every element that survives produces transparency, inspection or adaptation.
- The three pillars are transparency, inspection and adaptation. Transparency means the emergent process and work are visible to those performing and receiving it; inspection without transparency is misleading and wasteful; adaptation becomes more difficult when people are not empowered or self-managing.
- The five Scrum Values are commitment, focus, openness, respect and courage. Living them brings the pillars to life and builds trust, and the Guide ties successful use of Scrum directly to people becoming more proficient in them.
- The Scrum Team has three accountabilities and no sub-teams or hierarchies: one Product Owner, one Scrum Master and Developers. It is typically ten or fewer people, cross-functional and self-managing, focused on one Product Goal at a time.
- The Product Owner is accountable for maximizing the value of the product, and for Product Backlog management: developing and explicitly communicating the Product Goal, creating and clearly communicating items, ordering them, and ensuring the Backlog is transparent, visible and understood. The work may be delegated; the accountability may not.
- The Developers are always accountable for creating a plan for the Sprint (the Sprint Backlog), instilling quality by adhering to a Definition of Done, adapting their plan each day toward the Sprint Goal, and holding each other accountable as professionals. Nobody tells them how to turn items into Increments.
- The Scrum Master is accountable for establishing Scrum as defined in the Guide and for the Scrum Team's effectiveness. They are a true leader who serves the team, the Product Owner and the organization, and they cause the removal of impediments rather than necessarily removing every one personally.
- The Sprint is a fixed-length event of one month or less and is the container for all other events. A new Sprint starts immediately after the previous one concludes, which is what makes the cadence continuous. Only the Product Owner may cancel a Sprint, and only when the Sprint Goal becomes obsolete.
- Sprint Planning has three topics: why this Sprint is valuable (which produces the Sprint Goal), what can be Done this Sprint (the Developers select items, discussing this with the Product Owner), and how the chosen work will get done (the Developers' plan). The Sprint Goal must be finalised before the event ends.
- The Daily Scrum is a fifteen-minute event for the Developers, held every day of the Sprint at the same time and place. It inspects progress toward the Sprint Goal, adapts the Sprint Backlog, and produces an actionable plan for the next day. The Developers choose whatever structure they want; the three questions are no longer prescribed.
- The Sprint Review inspects the outcome of the Sprint with key stakeholders and determines future adaptations, producing a revised Product Backlog. It is a working session rather than a status meeting, and it should never be considered a gate to releasing value.
- The Sprint Retrospective concludes the Sprint and plans ways to increase quality and effectiveness. It inspects individuals, interactions, processes, tools and the Definition of Done, and the most impactful improvements are addressed as soon as possible, possibly by adding them to the next Sprint Backlog.
- Timeboxes for a one-month Sprint: Sprint Planning eight hours, Sprint Review four hours, Sprint Retrospective three hours, Daily Scrum fifteen minutes. The first three are usually shorter for shorter Sprints; the Daily Scrum stays fifteen minutes regardless.
- There are three artifacts, each with a commitment: the Product Backlog commits to the Product Goal, the Sprint Backlog commits to the Sprint Goal, and the Increment commits to the Definition of Done. The commitments reinforce empiricism and the Scrum Values.
- Work is not part of an Increment unless it meets the Definition of Done. Multiple Increments may be created within a Sprint, each is additive to all prior Increments and thoroughly verified, and an Increment may be delivered to stakeholders before the Sprint ends.
- During the 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.
Domain 2: Developing People and Teams
- Self-managing means the Scrum Team internally decides who does what, when and how. It is autonomy over the work within the framework, not over the framework itself, so the events, artifacts and accountabilities remain.
- Cross-functional means the members collectively have all the skills necessary to create value each Sprint. It is a property of the team rather than of each individual, and the test is whether the team can produce a Done Increment without depending on anyone outside it.
- The organization structures and empowers the Scrum Team to manage its own work. Where that empowerment is missing, the constraint sits outside the team and is an organizational impediment rather than a coaching problem.
- The Scrum Master serves the Scrum Team by coaching its members in self-management and cross-functionality, helping the team focus on Increments that meet the Definition of Done, causing the removal of impediments, and ensuring events take place within their timebox.
- The Scrum Master serves the Product Owner by helping find techniques for Product Goal definition and Product Backlog management, helping the team understand the need for clear and concise items, helping establish empirical product planning, and facilitating stakeholder collaboration as requested or needed.
- The Scrum Master serves the organization by leading, training and coaching it in Scrum adoption, planning and advising Scrum implementations, helping employees and stakeholders understand an empirical approach, and removing barriers between stakeholders and Scrum Teams.
- Coaching aims at the team solving its next problem without help. A Scrum Master who resolves every issue personally builds a dependency, which is the opposite of what the accountability for effectiveness pursues.
- The Scrum Master holds no authority over the team's work. They do not assign items, approve technical decisions, set the Sprint Goal, order the Product Backlog, or assess individual performance.
- Transparency depends on people being willing to say what is wrong, so a team that raises no problems is more likely to be unsafe than unobstructed. Courage and openness are what make honest inspection possible.
- Individual productivity measures and inter-team velocity comparisons distort behaviour. The Scrum Team is accountable as a unit for a valuable, useful Increment, and outcome measures answer the question that activity counts cannot.
- Retrospective improvements should be few and visible. The Guide says the most impactful are addressed as soon as possible, possibly by adding them to the Sprint Backlog, which is what stops them from losing to product work.
- Conflict between team members is within the team's own accountability, since the Developers hold each other accountable as professionals and interactions are explicitly inspected in the Retrospective. Facilitation builds that capability; escalation removes it.
- Stable, cohesive teams matter. Constant reassignment resets shared understanding, and split membership across two teams works against both the cohesion and the focus the Guide describes.
- An unresponsive dependency, an unavailable Product Owner or an organizational policy that blocks Done are all impediments for the Scrum Master to make visible and pursue, not conditions for the team to work around indefinitely.
Domain 3: Managing Products with Agility
- The Product Backlog is an emergent, ordered list of what is needed to improve the product, and the single source of work undertaken by the Scrum Team. Defects, technical work and internal-user improvements all belong in it and are ordered against everything else.
- The Product Goal is the Product Backlog's commitment and describes a future state of the product the team plans against. A Scrum Team focuses on one at a time and must fulfil or abandon it before taking on the next; abandonment is a legitimate outcome rather than a failure.
- Ordering is a value-versus-cost trade-off. The Product Owner decides, informed by the Developers' sizing, dependencies and risk. Anyone wanting to change the Product Backlog does so by convincing the Product Owner, and the organization must respect those decisions.
- Maximizing value means deciding what not to build as much as what to build. A Backlog that only grows records requests without expressing a decision, and it fails the requirement to be transparent, visible and understood.
- Items ready for selection are those the Scrum Team can Done within one Sprint. They usually reach that state through refinement, which is an ongoing activity rather than a Scrum event, with no timebox and no prescribed attendees.
- The Developers who will do the work are responsible for sizing it. The Product Owner may influence them by helping them understand and select trade-offs, but does not set the number.
- Item attributes such as description, order and size often vary with the domain of work. The Guide names examples rather than requirements, and defines no Definition of Ready.
- Scrum replaces prediction with forecasting. A forecast is built from the ordered Backlog and actual delivery evidence, and it is refreshed as Increments accumulate rather than held constant for the appearance of stability.
- Being Done makes an Increment releasable; whether to release is a separate Product Owner value decision. An Increment may be delivered before the Sprint ends, and the Sprint Review is never a release gate.
- The Sprint Review is where the team and stakeholders review what was accomplished and what has changed in their environment, then collaborate on what to do next. Its result is a revised Product Backlog defining the probable next items.
- Empiricism applies to product decisions too. Where value is assumed rather than known, a small experiment converts the assumption into evidence for a fraction of the cost of building the whole item.
- Value should be expressed as the outcome an item is expected to produce, which makes items comparable and makes it possible to check afterwards whether the value appeared. Output measures such as items closed or points completed do not.
- Cost of delay matters: two items of equal value are not equally urgent if one loses value rapidly. Regulatory exposure, competitive change and deadlines all enter ordering as value rather than as exceptions to it.
- Multiple Scrum Teams on one product share one Product Goal, one Product Backlog and one Product Owner, and must mutually define and comply with the same Definition of Done.
PSM I exam tips
- Know the exact numbers cold: Sprint one month or less; Sprint Planning eight hours, Sprint Review four, Retrospective three, Daily Scrum fifteen minutes; typically ten or fewer people; three accountabilities, five events counting the Sprint, three artifacts, three commitments, five values, three pillars. A large share of PSM I questions turn on one of these.
- Separate the artifacts from their commitments. The Definition of Done and the Product Goal are commitments, not artifacts; the three artifacts are the Product Backlog, the Sprint Backlog and the Increment. Questions that list four plausible items are usually testing this.
- When a question describes a problem, prefer the answer that makes something transparent and lets the accountable people decide. Answers where the Scrum Master decides, assigns, approves or reports are almost always wrong, and so are answers that skip an event or lower the Definition of Done.
- Remember what is fixed and what flexes inside a Sprint: the Sprint Goal is fixed and quality does not decrease, while scope may be clarified and renegotiated with the Product Owner as more is learned. Only the Product Owner may cancel a Sprint, and only when the Sprint Goal becomes obsolete.
- Watch for wording the Guide deliberately avoids. There is no project manager, no team lead, no Definition of Ready, no velocity, no story points, no hardening Sprint, no acceptance step by the Product Owner, and no three mandatory Daily Scrum questions. Options containing these are usually distractors.
- The 85 percent pass mark leaves room for about twelve wrong answers out of eighty, so read the whole Scrum Guide at least twice and take timed practice at full length. Watch the clock: 60 minutes for 80 questions is about 45 seconds each.
Study guide FAQ
What is the PSM I exam format and pass mark?
PSM I is 80 questions in 60 minutes, made up of multiple choice, multiple answer and true/false items, and you need 85 percent to pass, which is 68 correct answers. It is taken online, is open book in practice, and is based on the Scrum Guide of November 2020. The assessment does not expire and there is no renewal requirement.
Is reading the Scrum Guide enough to pass PSM I?
The Scrum Guide is the sole source of truth for the assessment, so reading it thoroughly is essential, but most questions are situational rather than definitional. They describe a team, a manager or a stakeholder doing something and ask what the framework calls for, which means you need to be able to reason from the Guide rather than recall sentences from it. Practising with realistic questions is what closes that gap.
What are the three Professional Scrum Competencies PSM I covers?
Understanding and Applying the Scrum Framework covers empiricism, the Scrum Values, the accountabilities, the events, the artifacts and their commitments. Developing People and Teams covers self-management, cross-functionality, coaching, facilitation and organizational impediments. Managing Products with Agility covers Product Backlog management, value, forecasting and stakeholder collaboration. Scrum.org publishes Focus Areas rather than numeric weights, but the framework competency carries the largest share of questions.
What are the most common reasons candidates fail PSM I?
The three recurring causes are guessing on the exact timeboxes and numbers, confusing commitments with artifacts, and choosing answers where the Scrum Master directs, decides or reports rather than coaches and makes things transparent. A fourth is running out of time, since 80 questions in 60 minutes allows about 45 seconds each and leaves little room to deliberate.
Do I need PSM I before PSM II or PSPO I?
No. Scrum.org sets no prerequisites between its assessments, so you can attempt PSM II or PSPO I without holding PSM I. In practice PSM I is the usual starting point because it establishes the framework understanding the others build on, and the same Scrum Guide underpins all of them.