When should I use it?

In the last few days before the exam, once you have already read the notes. A cheat sheet is a recall aid — it refreshes things you have learned and forgotten. It is a poor way to meet an idea for the first time, because it gives you the conclusion without the reasoning that makes it stick.

Can I pass the PSM I from the cheat sheet alone?

Very unlikely. The PSM I asks you to apply knowledge to scenarios, and a list of facts does not teach application. Use it to confirm what you already know and to find the gaps — then go back to the lesson behind any fact that reads as new.

Is it kept up to date?

The PSM I cheat sheet is generated from the published lessons every time the page loads, so it updates itself the moment a lesson changes. There is no separately-maintained copy to fall out of date.

PSM I last-day review

PSM I cheat sheet — every exam topic on one page

83 key facts across 3 exam domains — every topic on the PSM I blueprint, with the exam pattern behind each. A condensed cheat sheet, distilled from the full PSM I revision notes. Skim it the week of your exam.

Updated 31 Oct 2026

Understanding and Applying the Scrum Framework

46% of the exam

PSM I Scrum Theory: Empiricism, the Three Pillars and the Scrum Values

Scrum is a lightweight, purposefully incomplete framework for generating value through adaptive solutions to complex problems; its rules guide relationships and interactions, not detailed tasks.
Scrum is founded on empiricism (knowledge from experience, decisions on what is observed) and lean thinking (reduce waste, focus on the essentials).
The iterative, incremental approach optimizes predictability and controls risk: each Sprint gives real data and exposes wrong assumptions early.
The pillars are transparency, inspection and adaptation; transparency enables inspection and inspection enables adaptation.
Inspection without transparency is misleading and wasteful; inspection without adaptation is pointless.
Adapt as soon as possible, the moment something new is learned; adaptation is harder when people are not empowered or self-managing.
The five Scrum Values are commitment, focus, openness, respect and courage; transparency, trust and collaboration are not among them.
When the team and the people it works with live the values, the pillars come to life and build trust; decisions should reinforce the values, never undermine them.
Scrum is immutable and exists only in its entirety, but it works well as a container for other practices; Scrum's groups hold skills collectively and share or acquire them as needed.

How the exam tests this

Questions on this topic are short and exact, grounded in the Scrum Definition, Scrum Theory, Scrum Values and the Guide's purpose and end note. Expect recall of the pillars, the values and the definitions of empiricism, lean thinking and the iterative, incremental approach, often with distractors that swap a pillar for a value or use near-correct folk-Scrum wording. Scenario items describe a team or organization and ask which pillar is failing (look for the first broken link), which value a behavior shows, when to adapt, or whether a change keeps the team within Scrum. Some items are multiple response, asking for two statements the Guide supports.

PSM I Scrum Team: Developers, Product Owner and Scrum Master Accountabilities

A Scrum Team is one Scrum Master, one Product Owner and Developers: one cohesive unit, no sub-teams, no hierarchies, one Product Goal at a time.
Teams are typically 10 or fewer people; a team that grows too large reorganizes into several cohesive teams that share one Product Goal, Product Backlog and Product Owner.
Cross-functional means the team together has every skill needed to create value each Sprint, so a Done Increment never waits on an outside group.
The entire Scrum Team is accountable for a valuable, useful Increment every Sprint and is responsible for all product-related activities, from stakeholder collaboration to operation and R&D.
Developers are everyone in the team creating any part of the Increment; they own the Sprint plan, build quality in through the Definition of Done, adapt daily and hold each other accountable.
The Product Owner is accountable for maximizing value and for Product Backlog management; the work can be delegated, the accountability cannot.
The Product Owner is one person, not a committee; others change the Product Backlog by convincing the Product Owner, and the organization respects those decisions.
The Scrum Master is accountable for establishing Scrum and for the team's effectiveness, improving practices within the framework, as a true leader who serves.
The Scrum Master coaches, facilitates and causes impediments to be removed; the Scrum Master never assigns work, orders the backlog or inspects quality for the team.

How the exam tests this

Questions on the Scrum Team are short and exact, grounded in the wording of the 2020 Scrum Guide: who makes up the team, how large it typically is, what cross-functional means, what the whole team owns, and which of the three accountabilities owns a given decision or outcome. Many are brief scenarios in which a stakeholder, manager, Product Owner or Developer does something and you judge whether it fits the Guide or who should act. Distractors are usually near-correct: an option that hands a decision to the wrong accountability, an older-Guide term such as Development Team or 3 to 9 Developers, a folk-Scrum practice such as a Scrum Master who assigns work or inspects quality, or a Product Owner committee. Some items are multiple response, asking for two statements the Guide supports.

PSM I Scrum Events: The Sprint, Planning, Daily Scrum, Review and Retrospective

The Sprint is fixed length, one month or less, contains all other events, and the next Sprint starts immediately; it neither extends nor ends early.
During a Sprint the Sprint Goal is protected and quality does not decrease, while scope may be renegotiated with the Product Owner and the Product Backlog refined.
Only the Product Owner can cancel a Sprint, and only when the Sprint Goal has become obsolete.
Timeboxes are maximums: 8 h Planning, 4 h Review, 3 h Retrospective for a one-month Sprint (usually less for shorter ones) and 15 minutes for the Daily Scrum; an event ends when its purpose is met.
Sprint Planning answers why, what and how; the whole team defines the Sprint Goal before Planning ends, the Developers select items with the Product Owner, and how the work is done is solely the Developers' call.
Past performance, upcoming capacity and the Definition of Done make the Developers' forecast more confident.
The Daily Scrum is for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog; its structure is theirs, and it is not the only time they re-plan.
The Sprint Review is a working session with stakeholders on what to do next, never a release gate; it inspects the sum of the Sprint's Increments.
The Retrospective inspects individuals, interactions, processes, tools and the Definition of Done, addresses the most impactful improvements as soon as possible, and concludes the Sprint.

How the exam tests this

Questions on the Scrum events are mostly short items grounded in the Scrum Guide 2020, about half of them brief team scenarios, with some multiple-answer items. They ask for an event's purpose or timebox, who decides or takes part, what is allowed during a Sprint, or the best response when a team, manager or stakeholder bends a rule. The difficulty comes from near-correct distractors: rules from the 2017 Guide, folk practice such as status-report stand-ups, sign-off reviews and fixed durations, and options that swap one event's purpose for another's. Expect to tell timeboxes as maximums from required durations, scope renegotiation from quality cuts, the Product Owner's authority from the Developers' ownership of how the work gets done, and the Sprint Review as a working session from a release gate.

PSM I Scrum Artifacts, Commitments and the Definition of Done

Each artifact contains one commitment: Product Backlog with the Product Goal, Sprint Backlog with the Sprint Goal, Increment with the Definition of Done.
Artifacts represent work or value and maximize transparency; commitments add focus against which progress is measured and reinforce empiricism and the Scrum Values.
The Product Backlog is an emergent, ordered list of what is needed to improve the product and the single source of work; one product has one Product Backlog.
Refinement is ongoing and adds description, order and size; the Developers who will do the work size items; an item is ready when it can be Done within one Sprint.
The Product Goal is a future state of the product in the Product Backlog; the team fulfills or abandons one before taking on the next.
The Sprint Backlog is the Sprint Goal (why), selected items (what) and a plan (how), by and for the Developers, updated throughout the Sprint.
The Sprint Goal is the single objective for the Sprint, a commitment by the Developers that leaves flexibility in the exact work and creates coherence.
An Increment is additive, verified to work with all prior Increments and usable; it is born when an item meets the Definition of Done, and several can be created in a Sprint.
Work that does not meet the Definition of Done cannot be released or presented at the Sprint Review; it returns to the Product Backlog.
An organizational Definition of Done is a minimum; otherwise the Scrum Team creates one; teams on one product share one; it is inspected at the Sprint Retrospective.

How the exam tests this

Questions on the artifacts are mostly short items grounded in the Scrum Guide 2020, about two in five of them brief team scenarios, with a fair share of multiple-answer items. They ask which commitment belongs to which artifact, who sizes, owns or conforms to something, what the Guide says an artifact is, and the best response when a team handles backlogs, goals, Increments or the Definition of Done in a way the Guide does not support. Distractors lean on familiar practices that are not in the Guide, such as a Definition of Ready, story points, Product Owner acceptance, carrying unfinished work over and hardening Sprints.

Developing People and Teams

23% of the exam

PSM I Self-Managing Teams: Who Decides What in a Scrum Team

A self-managing Scrum Team decides internally who does what, when and how; it is also cross-functional, so it has the skills to act on those decisions.
The 2020 Scrum Guide moved from a self-organizing Development Team (who and how) to a self-managing Scrum Team (who, how and what).
There are no sub-teams or hierarchies in a Scrum Team: no member, however senior or however chosen, has the final say over the others' work.
The Developers decide how to turn items into a Done Increment, who works on what, how they track work and how they run the Daily Scrum.
The Developers who do the work size it and select Sprint items through discussion with the Product Owner; the Product Owner influences by explaining trade-offs.
Developers hold each other accountable as professionals and raise problems that threaten the Sprint Goal straight away.
Self-management stays inside Scrum: the Product Owner orders the Product Backlog, the Definition of Done is met in full, the Sprint Goal is not endangered and the Sprint is not extended.
Scope is renegotiated with the Product Owner when work turns out bigger than forecast or new work is requested mid-Sprint.
The Scrum Master coaches self-management and cross-functionality and facilitates decisions rather than making or assigning them.
Organizations structure and empower Scrum Teams to manage their own work, and the Scrum Team identifies its own improvements.

How the exam tests this

Questions on this topic check whether you can tell who owns a decision in a self-managing Scrum Team and where self-management stops. Expect short recall items on the Scrum Guide's wording (what self-managing means, who sizes work, who chooses the Daily Scrum format, who identifies improvements) and scenarios in which a Scrum Master, Product Owner, manager, stakeholder or senior Developer tries to assign, approve or decide something that belongs to someone else. Distractors are often older or folk Scrum: a Development Team as a separate sub-team, a tech lead with approval rights, the Scrum Master as task allocator, mandatory three questions or burndown charts, or treating self-management as permission to reorder the Product Backlog, skip the Definition of Done or extend a Sprint. Some items are multiple response and ask for two statements that match the Guide.

PSM I Facilitation and Coaching: How a Scrum Master Serves Without Directing

A facilitator owns the process; the group owns the outcome and the decisions.
The Scrum Master ensures events take place and are positive, productive and timeboxed; the Scrum Guide names no required facilitator, so events go ahead without the Scrum Master.
The Daily Scrum is the Developers' planning event; a Scrum Master collecting status updates turns it into a report, even inside 15 minutes.
The Sprint Review is a working session, and new requests go to the Product Owner; the Scrum Team chooses its own Retrospective improvements within the timebox.
Missing knowledge: teach. Knowledge present but stuck: coach. Mentors share experience; facilitators guide a group's process.
Coaching self-management means handing decisions back: answer with questions, surface risks, let the team try reversible ideas and inspect the result.
Facilitate conflicts the team can resolve; take causes beyond its control to people who can act.
Serve the Product Owner and the organization by building their capability and removing barriers, never by taking their accountability or becoming a new go-between.

How the exam tests this

Most questions in this topic are short scenarios that ask what the Scrum Master should do: a team asks the Scrum Master to decide, a manager wants an approval step, a stakeholder pushes for a feature, an event drifts, overruns or gets skipped, or two people are in conflict. Several options sound helpful, so the question is which one keeps each decision with the accountability that owns it while the Scrum Master serves through facilitating, coaching, teaching or making things transparent. Other items ask which stance fits a situation (teach versus coach), what the Scrum Guide does and does not say about facilitating events, and which facilitation technique fixes a specific group problem. Multiple-response items ask for the two actions that fit.

Managing Products with Agility

31% of the exam

PSM I Product Value and Stakeholders: Maximizing Value with Customers

The Product Owner is accountable for maximizing product value; the Scrum Guide does not prescribe how.
Value is evidenced by outcomes for users, customers and the organization, not by output such as velocity, Done-item counts or plan conformance.
EBM's four key value areas are Current Value, Unrealized Value, Time to Market and Ability to Innovate; lead time and satisfaction are measures inside them.
Value depends on context: revenue for some products, mission or citizen outcomes for others, employee outcomes for internal tools.
Stakeholders are outside the Scrum Team; customers (who buy or adopt) and users (who use) are both stakeholders and can disagree.
One Product Owner represents many stakeholders; others change the Product Backlog by convincing the Product Owner, whose decisions are visible in its content and order.
At the Sprint Review, stakeholders and the Scrum Team review results and changes in the environment and collaborate on what to do next; it is not an approval gate.
The Sprint Goal communicates why the Sprint is valuable to stakeholders; invited advisors at Sprint Planning give advice but decide nothing.
Developers may talk to users directly; what they learn goes to the Product Owner, who decides ordering.
Expected value is a hypothesis: release small and early, measure the targeted outcome, and adapt the Product Backlog.

How the exam tests this

Questions on this topic check whether you can tell evidence of value from evidence of activity, and who holds which decision when stakeholders are involved. Expect short recall items on the Scrum Guide's wording (whom the Product Owner represents, how the Product Backlog is changed, what happens at the Sprint Review, who may attend Sprint Planning, what the Sprint Goal communicates) and on the names and meaning of the four Evidence-Based Management key value areas. Scenario items put pressure on the Product Owner's decisions, show customers and users with different views, bring stakeholders into events, give Developers new information from users, and describe products whose value has not yet been tested with real users, then ask for the best response. Distractors are usually near-correct: an output measure dressed up as value, a measure named as a key value area, a stakeholder given approval power, or a sound idea applied at the wrong event. Some items are multiple response and ask for two answers.

PSM I Product Backlog Management: Ordering, Refinement and Sizing

The Product Backlog is an emergent, ordered list of what is needed to improve the product and the single source of work for the Scrum Team; the Product Goal is in it.
The Product Owner is accountable for the Product Goal, the items, their order and keeping the backlog transparent, visible and understood: one shared, current backlog, visible to stakeholders, in language its readers understand. Anyone wanting a change convinces the Product Owner.
No ordering technique is prescribed: value, risk, dependencies and learning can all shape the order, and every item has its own place rather than a shared priority label.
Refinement is an ongoing activity, not an event: no timebox, no 10% rule since the 2020 Guide, and it happens inside each Sprint with the Developers involved.
Detail grows as items approach selection; the Developers who will do the work size it, using whatever technique they choose.
An item is ready when it can be Done within one Sprint; split large items into thin end-to-end slices, not layers or activities. User stories and a Definition of Ready are optional.
Technical debt, experiments and side requests become visible Product Backlog items; qualities for every Increment belong in the Definition of Done.
The Product Owner can change the Product Backlog whenever a change is useful; that does not change the current Sprint Backlog, and teams on one product share one Product Backlog and refine together.

How the exam tests this

Questions in this topic are mostly short scenarios about who decides what and where work belongs: a stakeholder or manager wants an item moved, a Developer receives a request directly, a Product Owner refines alone or keeps the real order elsewhere, technical debt or favours are handled outside the backlog, or the order changes mid-Sprint. Other items check exact Scrum Guide wording against older or folk Scrum, such as whether refinement is an event, the removed 10% guideline, who sizes items, what makes an item ready, and whether user stories, story points or a Definition of Ready are required. Harder items combine two facts, for example ordering by risk or dependency rather than value alone, splitting into usable slices rather than layers, or several teams sharing one Product Backlog. Multiple-response items ask for the two statements or actions that fit.

PSM I Forecasting and Release Planning: Empirical Forecasts and Releasing Value

Only what has already happened, mainly Done work from past Sprints, may inform forward-looking decisions; upfront estimates and targets are not evidence.
Sprints enable predictability by inspecting and adapting progress toward the Product Goal at least every calendar month; their fixed length creates the consistency that keeps Sprints comparable.
Burn-downs, burn-ups and cumulative flows are optional practices that do not replace empiricism; the 2020 Guide removed the 2017 rules for tracking total work remaining.
Velocity is not in the Guide: it is team-specific, not comparable across teams, and inflated when made a target.
Only work meeting the Definition of Done is part of an Increment; there is no partial credit, and counting undone work makes forecasts overstate progress.
An Increment may be released before the Sprint ends, several Increments may be created per Sprint, and the Sprint Review is never a gate to releasing value.
Done means usable and releasable, not released; when to release is a value decision within the Product Owner's accountability, which can be delegated while the Product Owner stays accountable.
Scrum has no release planning event, release or hardening Sprint, or Sprint 0; needing a stabilization Sprint means the Definition of Done is not sufficient.
With a fixed date, flex scope by ordering for value and make the gap transparent early; never relax the Definition of Done or stretch Sprints.
A forecast is a range revised every Sprint, not a commitment; several teams on one product forecast from one Product Backlog and count only integrated work meeting a shared Definition of Done.

How the exam tests this

Questions on forecasting and release planning are mostly short items grounded in the Scrum Guide 2020, many of them brief scenarios with a Product Owner, manager or stakeholder, and some multiple-answer items. They ask what may inform a forecast, how Sprints create predictability, what status forecasting charts and velocity have, what counts as progress, when an Increment may be released and who decides, and how to respond to a fixed date or several teams sharing a product. The difficulty comes from near-correct distractors: rules from the 2017 Guide, folk practices such as release Sprints, hardening Sprints, Sprint 0 and release planning meetings, Sprint Review sign-offs, velocity comparisons and targets, partial credit for undone work, and forecasts treated as commitments. Some items ask you to spot the weakness in a forecast built from history that no longer matches current conditions, or to turn a recent throughput range into a forecast range.

Facts fresh? Prove it.

Drill PSM I practice questions with an explanation on every option.

Practice now

Where these PSM I facts came from

PSM I cheat sheet: your questions

Every key takeaway from all 9 PSM I revision lessons — 83 facts — pulled onto one page and grouped by exam domain, with the exam pattern behind each topic. It is a compression of the notes, not a separate set of content, so it can never contradict them.

Source

Exam structure, domain weights and scoring on this page come from the official PSM I exam guide.

Scrum.org Professional Scrum Master I (PSM I) certification page — Scrum.org