Are flashcards effective for the PSM I exam?

Yes. Flashcards use active recall — retrieving an answer from memory — which research shows is one of the most effective study methods, especially in short, spaced sessions. They're ideal for the PSM I's heavy terminology: time-boxes, accountabilities, artifacts, and the three commitments.

What topics do the PSM I flashcards cover?

The whole Scrum Guide 2020: theory and the five values, the Scrum Team and its three accountabilities, the five events and their time-boxes, the three artifacts and their commitments (Product Goal, Sprint Goal, Definition of Done), plus applying and scaling Scrum.

How should I study with these PSM I flashcards?

Burn in the facts first — the event time-boxes (Planning 8h, Daily 15min, Review 4h, Retro 3h) and the artifact-to-commitment pairings. Then mix the modes: flip to learn, type to test recall, match for speed, and quiz to check yourself before a full practice test.

Are the PSM I flashcards free?

Yes — 100% free, all four study modes, no paywall and no sign-up.

Do these flashcards match the current PSM I exam?

Yes. Every card is drawn from the current 2020 edition of the Scrum Guide, which is the only source the PSM I assessment is based on. Older 'roles' and 'three questions' terminology has been updated to the 2020 'accountabilities' wording.

A lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.

Knowledge comes from experience and decisions are made based on what is observed. Scrum is founded on empiricism (and lean thinking).

Reduces waste and focuses on the essentials. Together with empiricism, it is the foundation Scrum is built on.

The three pillars of empiricism

Transparency, Inspection, and Adaptation.

Transparency (pillar)

The emergent process and work must be visible to those performing and receiving it. Important decisions are based on the perceived state of the three artifacts.

Scrum artifacts and progress toward agreed goals must be inspected frequently and diligently to detect undesirable variances or problems.

If aspects of a process deviate outside acceptable limits or the product is unacceptable, the process or material being produced must be adjusted as soon as possible.

Why does transparency come first?

Inspection without transparency is misleading and wasteful, and decisions based on low-transparency artifacts are flawed. Transparency enables meaningful inspection, which enables adaptation.

The five Scrum Values

Commitment, Focus, Openness, Respect, and Courage.

The Scrum Team commits to achieving its goals and to supporting each other.

The team's primary focus is on the work of the Sprint to make the best possible progress toward its goals.

The Scrum Team and its stakeholders are open about the work and the challenges.

Scrum Team members respect each other to be capable, independent people, and are respected as such by the people they work with.

The Scrum Team members have the courage to do the right thing and to work on tough problems.

Why do the Scrum Values matter?

When embodied by the Scrum Team, the values bring the Scrum pillars of transparency, inspection, and adaptation to life and build trust.

Iterative and incremental

Scrum employs an iterative, incremental approach to optimize predictability and to control risk.

Is Scrum a methodology or a process?

Neither. Scrum is a framework — it is purposefully incomplete, defining only the parts required to implement Scrum theory. It is built upon by the people using it.

Yes. Scrum's framework is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety.

What complements Scrum?

Scrum wraps around existing practices or renders them unnecessary. Various processes, techniques, and methods can be employed within the framework.

What kind of problems is Scrum for?

Complex problems — where more is unknown than known and outcomes cannot be fully predicted up front.

Why use small teams in Scrum?

Smaller teams communicate better and are more productive. The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint — typically 10 or fewer people.

Cone of uncertainty (concept)

Uncertainty is highest at the start of a project and decreases as the work progresses and the team learns. Scrum's short cycles exploit this by re-planning frequently.

Definition of a complex domain

A domain where requirements and technology change and outcomes emerge. Scrum is designed for this, in contrast to simple/complicated work that suits a defined process.

Why does Scrum prescribe so little?

To maximize the team's autonomy and ability to self-manage, and to allow the framework to be applied across many domains. The 'how' is left to the people doing the work.

The Scrum Values build the trust that makes empiricism work; without trust, transparency suffers and inspection/adaptation become ineffective.

Where is Scrum defined?

In the Scrum Guide, authored and maintained by Ken Schwaber and Jeff Sutherland. The current normative version is the 2020 edition.

What did the 2020 Scrum Guide change about roles?

It replaced the word 'roles' with 'accountabilities' and stopped calling the Scrum Master/Product Owner/Developers 'roles within a team' — they are accountabilities within one Scrum Team.

What did the 2020 Scrum Guide add?

The Product Goal as a commitment to the Product Backlog, alongside the existing Sprint Goal and Definition of Done.

What did the 2020 Scrum Guide simplify?

It removed prescriptive language (e.g., the Daily Scrum 'three questions'), made Scrum less IT-focused, and emphasized one self-managing Scrum Team with no sub-teams or hierarchies.

'Done' increment each Sprint — why?

A usable, valuable Increment each Sprint maximizes transparency and enables empirical inspection of real, working product rather than plans or promises.

The fundamental unit of Scrum: one Scrum Master, one Product Owner, and Developers. There are no sub-teams or hierarchies. It is typically 10 or fewer people.

How many people are on a Scrum Team?

Typically 10 or fewer. Smaller teams communicate better and are more productive; if a team gets too large, consider reorganizing into multiple cohesive Scrum Teams sharing one product.

The three accountabilities in Scrum

Scrum Master, Product Owner, and Developers. (The 2020 Scrum Guide calls these accountabilities, not roles.)

Is the Scrum Team cross-functional?

Yes. Cross-functional means the team members collectively have all the skills necessary to create value each Sprint, without depending on others outside the team.

Is the Scrum Team self-managing?

Yes. Self-managing means the team internally decides who does what, when, and how — no one tells them how to turn Product Backlog items into value.

Who is accountable for creating value?

The whole Scrum Team is accountable for creating a valuable, useful Increment every Sprint.

Developers (accountability)

The Scrum Team members committed to creating any aspect of a usable Increment each Sprint. They create the plan for the Sprint (Sprint Backlog), instill quality via the Definition of Done, adapt their plan daily, and hold each other accountable as professionals.

Are the Developers held accountable individually or collectively?

Collectively. The Developers are accountable as a whole for the Increment; Scrum does not assign individual blame for Sprint outcomes.

Product Owner (accountability)

Accountable for maximizing the value of the product resulting from the work of the Scrum Team. Accountable for effective Product Backlog management.

Is the Product Owner one person or a committee?

One person. The Product Owner may represent the needs of many stakeholders in the Product Backlog, but it is a single person, not a committee.

Product Owner — Product Backlog management duties

Developing/communicating the Product Goal, creating/clearly communicating Product Backlog items, ordering the Product Backlog, and ensuring it is transparent, visible, and understood.

Can others change the Product Backlog?

Only with the Product Owner's agreement. For the Product Owner to succeed, the whole organization must respect their decisions — visible in the ordering of the Product Backlog.

May the Product Owner delegate Product Backlog work?

Yes, the Product Owner may delegate the work (e.g., to Developers), but remains accountable for it.

Scrum Master (accountability)

Accountable for establishing Scrum as defined in the Scrum Guide, and for the Scrum Team's effectiveness. The Scrum Master is a true leader who serves the Scrum Team and the larger organization.

Scrum Master leadership style

A true leader who serves (servant leadership). The Scrum Master helps the team improve its practices within the Scrum framework rather than commanding or controlling it.

Your FREE PSM I Flashcards 2026 – 200+ Cards

Realistic, PSM I exam-style flashcards on the Scrum Guide 2020 — flip, match, type, and quiz yourself on theory, accountabilities, events, and artifacts.

Master cards to boost your scoreMaster cards to raise your exam readiness score

How well do you know them?

PSM I Flashcards

Scrum: A lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.
Empiricism: Knowledge comes from experience and decisions are made based on what is observed. Scrum is founded on empiricism (and lean thinking).
Lean thinking: Reduces waste and focuses on the essentials. Together with empiricism, it is the foundation Scrum is built on.
The three pillars of empiricism: Transparency, Inspection, and Adaptation.
Transparency (pillar): The emergent process and work must be visible to those performing and receiving it. Important decisions are based on the perceived state of the three artifacts.
Inspection (pillar): Scrum artifacts and progress toward agreed goals must be inspected frequently and diligently to detect undesirable variances or problems.
Adaptation (pillar): If aspects of a process deviate outside acceptable limits or the product is unacceptable, the process or material being produced must be adjusted as soon as possible.
Why does transparency come first?: Inspection without transparency is misleading and wasteful, and decisions based on low-transparency artifacts are flawed. Transparency enables meaningful inspection, which enables adaptation.
The five Scrum Values: Commitment, Focus, Openness, Respect, and Courage.
Commitment (value): The Scrum Team commits to achieving its goals and to supporting each other.
Focus (value): The team's primary focus is on the work of the Sprint to make the best possible progress toward its goals.
Openness (value): The Scrum Team and its stakeholders are open about the work and the challenges.
Respect (value): Scrum Team members respect each other to be capable, independent people, and are respected as such by the people they work with.
Courage (value): The Scrum Team members have the courage to do the right thing and to work on tough problems.
Why do the Scrum Values matter?: When embodied by the Scrum Team, the values bring the Scrum pillars of transparency, inspection, and adaptation to life and build trust.
Iterative and incremental: Scrum employs an iterative, incremental approach to optimize predictability and to control risk.
Is Scrum a methodology or a process?: Neither. Scrum is a framework — it is purposefully incomplete, defining only the parts required to implement Scrum theory. It is built upon by the people using it.
Is Scrum immutable?: Yes. Scrum's framework is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety.
What complements Scrum?: Scrum wraps around existing practices or renders them unnecessary. Various processes, techniques, and methods can be employed within the framework.
What kind of problems is Scrum for?: Complex problems — where more is unknown than known and outcomes cannot be fully predicted up front.
Why use small teams in Scrum?: Smaller teams communicate better and are more productive. The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint — typically 10 or fewer people.
Cone of uncertainty (concept): Uncertainty is highest at the start of a project and decreases as the work progresses and the team learns. Scrum's short cycles exploit this by re-planning frequently.
Definition of a complex domain: A domain where requirements and technology change and outcomes emerge. Scrum is designed for this, in contrast to simple/complicated work that suits a defined process.
Why does Scrum prescribe so little?: To maximize the team's autonomy and ability to self-manage, and to allow the framework to be applied across many domains. The 'how' is left to the people doing the work.
Trust in Scrum: The Scrum Values build the trust that makes empiricism work; without trust, transparency suffers and inspection/adaptation become ineffective.
Where is Scrum defined?: In the Scrum Guide, authored and maintained by Ken Schwaber and Jeff Sutherland. The current normative version is the 2020 edition.
What did the 2020 Scrum Guide change about roles?: It replaced the word 'roles' with 'accountabilities' and stopped calling the Scrum Master/Product Owner/Developers 'roles within a team' — they are accountabilities within one Scrum Team.
What did the 2020 Scrum Guide add?: The Product Goal as a commitment to the Product Backlog, alongside the existing Sprint Goal and Definition of Done.
What did the 2020 Scrum Guide simplify?: It removed prescriptive language (e.g., the Daily Scrum 'three questions'), made Scrum less IT-focused, and emphasized one self-managing Scrum Team with no sub-teams or hierarchies.
'Done' increment each Sprint — why?: A usable, valuable Increment each Sprint maximizes transparency and enables empirical inspection of real, working product rather than plans or promises.
The Scrum Team: The fundamental unit of Scrum: one Scrum Master, one Product Owner, and Developers. There are no sub-teams or hierarchies. It is typically 10 or fewer people.
How many people are on a Scrum Team?: Typically 10 or fewer. Smaller teams communicate better and are more productive; if a team gets too large, consider reorganizing into multiple cohesive Scrum Teams sharing one product.
The three accountabilities in Scrum: Scrum Master, Product Owner, and Developers. (The 2020 Scrum Guide calls these accountabilities, not roles.)
Is the Scrum Team cross-functional?: Yes. Cross-functional means the team members collectively have all the skills necessary to create value each Sprint, without depending on others outside the team.
Is the Scrum Team self-managing?: Yes. Self-managing means the team internally decides who does what, when, and how — no one tells them how to turn Product Backlog items into value.
Who is accountable for creating value?: The whole Scrum Team is accountable for creating a valuable, useful Increment every Sprint.
Developers (accountability): The Scrum Team members committed to creating any aspect of a usable Increment each Sprint. They create the plan for the Sprint (Sprint Backlog), instill quality via the Definition of Done, adapt their plan daily, and hold each other accountable as professionals.
Are the Developers held accountable individually or collectively?: Collectively. The Developers are accountable as a whole for the Increment; Scrum does not assign individual blame for Sprint outcomes.
Product Owner (accountability): Accountable for maximizing the value of the product resulting from the work of the Scrum Team. Accountable for effective Product Backlog management.
Is the Product Owner one person or a committee?: One person. The Product Owner may represent the needs of many stakeholders in the Product Backlog, but it is a single person, not a committee.
Product Owner — Product Backlog management duties: Developing/communicating the Product Goal, creating/clearly communicating Product Backlog items, ordering the Product Backlog, and ensuring it is transparent, visible, and understood.
Can others change the Product Backlog?: Only with the Product Owner's agreement. For the Product Owner to succeed, the whole organization must respect their decisions — visible in the ordering of the Product Backlog.
May the Product Owner delegate Product Backlog work?: Yes, the Product Owner may delegate the work (e.g., to Developers), but remains accountable for it.
Scrum Master (accountability): Accountable for establishing Scrum as defined in the Scrum Guide, and for the Scrum Team's effectiveness. The Scrum Master is a true leader who serves the Scrum Team and the larger organization.
Scrum Master leadership style: A true leader who serves (servant leadership). The Scrum Master helps the team improve its practices within the Scrum framework rather than commanding or controlling it.
Scrum Master service to the Scrum Team: Coaching team members in self-management and cross-functionality, helping focus on creating high-value Increments, removing impediments, and ensuring Scrum events happen and are positive, productive, and within the time-box.
Scrum Master service to the Product Owner: Helping find techniques for effective Product Goal definition and Product Backlog management, helping the team understand the need for clear/concise items, and facilitating stakeholder collaboration as requested.
Scrum Master service to the organization: Leading, training, and coaching the organization in its Scrum adoption; planning and advising Scrum implementations; helping employees and stakeholders understand empirical work and removing barriers between stakeholders and Scrum Teams.
Is the Scrum Master a project manager or boss?: No. The Scrum Master has no authority over people on the team; they lead by serving and coaching. They are accountable for the team's effectiveness, not for assigning tasks.
Impediment (definition): Anything that slows or blocks the Scrum Team from making progress. The Scrum Master causes the removal of impediments — ideally by helping the team become able to remove them itself.
Should the Scrum Master assign tasks?: No. The Developers self-manage and decide who does what. A Scrum Master assigning work undermines self-management.
What if the team becomes highly self-reliant?: The Scrum Master steps back, intervening less, and shifts toward coaching and organizational improvement — the goal is a team that can sustain itself.
Whole-team accountability for quality: The entire Scrum Team is accountable for creating a 'Done', usable Increment; the Definition of Done makes quality everyone's responsibility, not just testers'.
Can one person hold two accountabilities?: The Scrum Guide names three distinct accountabilities on one team. While not explicitly forbidden, combining Scrum Master and Product Owner is discouraged because their focuses conflict.
Stakeholder (definition): Anyone outside the Scrum Team with an interest in the product — e.g., customers, users, sponsors. They give feedback, most actively at the Sprint Review.
Self-management vs. self-organization: The 2020 Scrum Guide uses 'self-managing': the team chooses who, what, when, and how. It broadens the earlier 'self-organizing' (which mostly covered how the work is done).
Why hold Developers collectively accountable?: Collective accountability fosters shared ownership and collaboration toward the Sprint Goal, rather than siloed individual outputs.
The five Scrum events: The Sprint (a container for all others), Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective.
The Sprint (event): A fixed-length event of one month or less, the heartbeat of Scrum, in which ideas are turned into value. A new Sprint starts immediately after the previous one concludes. All work happens within Sprints.
How long is a Sprint?: One month or less — a consistent duration the team chooses. Shorter Sprints generate more learning cycles and limit risk to a smaller time and cost.
What happens 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.
Why keep Sprints short?: Short Sprints limit cost and risk to one calendar period, enable more frequent inspection and adaptation, and produce learning faster.
Who can cancel a Sprint?: Only the Product Owner can cancel a Sprint.
When should a Sprint be cancelled?: When the Sprint Goal becomes obsolete — e.g., the company changes direction or market/technology conditions change. Cancellations are rare because Sprints are short.
What happens to work when a Sprint is cancelled?: Any completed and 'Done' Product Backlog items are reviewed; if potentially releasable, the Product Owner typically accepts them. All incomplete items are re-estimated and returned to the Product Backlog.
Sprint Planning (event): Initiates the Sprint by laying out the work to be performed. The whole Scrum Team collaborates to create the plan. Time-boxed to a maximum of 8 hours for a one-month Sprint (shorter for shorter Sprints).
Sprint Planning topic 1 — Why is this Sprint valuable?: The Product Owner proposes how the product could increase value this Sprint; the whole team collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.
Sprint Planning topic 2 — What can be Done this Sprint?: The Developers, in conversation with the Product Owner, choose Product Backlog items for the Sprint, refining them as needed. Forecasting work is hard; experience and the Definition of Done help.
Sprint Planning topic 3 — How will the chosen work get done?: For each selected item, the Developers plan the work needed to create a 'Done' Increment, often decomposing items into smaller work items of a day or less. How they do this is at their sole discretion.
Sprint Planning time-box: Maximum 8 hours for a one-month Sprint; usually shorter for shorter Sprints.
Output of Sprint Planning: The Sprint Goal, the Product Backlog items selected for the Sprint, and the plan for delivering them — together, the Sprint Backlog.
Daily Scrum (event): A 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. Held the same time and place every working day.
Daily Scrum time-box: 15 minutes, every working day of the Sprint, at the same time and place to reduce complexity.
Who attends the Daily Scrum?: The Developers. If the Product Owner or Scrum Master are actively working on Sprint Backlog items, they participate as Developers.
Does the Scrum Master run the Daily Scrum?: No. It is by and for the Developers. The Scrum Master ensures it happens and stays within 15 minutes but does not have to attend or lead it.
Are the 'three questions' required at the Daily Scrum?: No. The 2020 Scrum Guide removed the mandatory three questions. Developers can choose whatever structure and technique they want, as long as the Daily Scrum focuses on progress toward the Sprint Goal.
Purpose of the Daily Scrum: Inspect progress toward the Sprint Goal and adapt the Sprint Backlog; improve communication, identify impediments, promote quick decision-making, and reduce the need for other meetings.
Sprint Review (event): Held at the end of the Sprint to inspect the outcome and determine future adaptations. The Scrum Team presents results to key stakeholders and progress toward the Product Goal is discussed. Max 4 hours for a one-month Sprint.
Sprint Review time-box: Maximum 4 hours for a one-month Sprint; shorter for shorter Sprints.
Is the Sprint Review a status meeting?: No. It is a working session — a collaborative review of the Increment with stakeholders to gather feedback and adapt the Product Backlog. The Scrum Team should avoid limiting it to a one-way presentation.
Who attends the Sprint Review?: The Scrum Team and key stakeholders invited by the Product Owner. Stakeholder feedback is the main reason to hold it.
Output of the Sprint Review: A revised Product Backlog that defines the probable next items. The Product Backlog may be adjusted to meet new opportunities.
Sprint Retrospective (event): Closes the Sprint. The Scrum Team inspects how the last Sprint went regarding individuals, interactions, processes, tools, and its Definition of Done, and plans ways to increase quality and effectiveness. Max 3 hours for a one-month Sprint.
Sprint Retrospective time-box: Maximum 3 hours for a one-month Sprint; shorter for shorter Sprints.
Purpose of the Sprint Retrospective: To plan ways to increase quality and effectiveness. The team discusses what went well, what problems were encountered, and how they were (or were not) solved, then identifies the most helpful changes.
Who attends the Sprint Retrospective?: The whole Scrum Team — Scrum Master, Product Owner, and Developers — inspecting how they worked together.
Order of the Scrum events within a Sprint: Sprint Planning starts the Sprint; the Daily Scrum happens each day; the Sprint Review and then the Sprint Retrospective close the Sprint.
Why are the events time-boxed?: Time-boxes create regularity, minimize the need for other meetings, and ensure each event has a maximum duration so it does not waste time. Each event is a formal opportunity to inspect and adapt.
Can Scrum events be skipped?: No. Failing to run any event reduces transparency and forgoes an opportunity to inspect and adapt — that is no longer Scrum. The Sprint contains all the other events.
Is the Sprint itself an event?: Yes. The Sprint is a container event that holds all other Scrum events; they all occur within it.
What is the relationship between events and empiricism?: Each event is a formal opportunity to inspect and adapt Scrum artifacts. They are designed to enable the transparency, inspection, and adaptation the framework relies on.
The three Scrum artifacts: The Product Backlog, the Sprint Backlog, and the Increment. Each represents work or value and is designed to maximize transparency.
Each artifact's commitment: Product Backlog → Product Goal; Sprint Backlog → Sprint Goal; Increment → Definition of Done. Commitments reinforce empiricism and the Scrum Values.
Why do artifact commitments exist?: Each commitment provides information that enhances transparency and focus, against which progress can be measured.
Product Backlog (artifact): An emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
Product Goal (commitment): The commitment for the Product Backlog. It describes a future state of the product and serves as a long-term objective for the Scrum Team. The team must fulfill (or abandon) one Product Goal before taking on the next.
Product Backlog refinement (definition): The act of breaking down and further defining Product Backlog items into smaller, more precise items, adding detail such as description, order, and size. It is an ongoing activity, not a separate event.
Who does Product Backlog refinement?: The Developers who will do the work are responsible for sizing; the Product Owner may influence them by helping understand and select trade-offs. Refinement is a collaborative, ongoing activity.
How much of the Product Backlog is refined?: Only as much as needed. Items that can be 'Done' within a Sprint are deemed ready for selection in Sprint Planning. There is no rule to refine the entire backlog.
Who orders the Product Backlog?: The Product Owner. Ordering reflects value, risk, dependencies, and other factors so the most valuable work is done first.
When may the Product Backlog be reordered?: At any time. The Product Owner can re-order the Product Backlog whenever priorities change, but for it to be respected the whole organization must honor those decisions.
Sprint Backlog (artifact): Composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), plus an actionable plan for delivering the Increment (how). It is a plan by and for the Developers.
Sprint Goal (commitment): The commitment for the Sprint Backlog. The single objective for the Sprint. It creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.
Can the Sprint Goal change during the Sprint?: No. The Sprint Goal is committed during Sprint Planning and added to the Sprint Backlog; it should not change. If the work turns out different than expected, scope is renegotiated with the Product Owner without affecting the Sprint Goal.
Who owns the Sprint Backlog?: The Developers. It is a highly visible, real-time picture of the work they plan to accomplish during the Sprint, updated throughout as they learn more.
Increment (artifact): A concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring all Increments work together. It must be usable.
What does it mean that an Increment is additive?: Each Increment adds to and works with all previous Increments; together they form a coherent, usable product, verified to function as a whole.
When is an Increment created?: Multiple Increments may be created within a Sprint. An Increment is born the moment a Product Backlog item meets the Definition of Done.
Definition of Done (commitment): The commitment for the Increment. A formal description of the state of the Increment when it meets the quality measures required for the product. Work doesn't count toward an Increment until it meets the Definition of Done.
Who sets the Definition of Done?: If it is an organizational standard, all Scrum Teams must follow it as a minimum. If not, the Scrum Team must create one appropriate for the product.
What if a Product Backlog item does not meet the Definition of Done?: It cannot be released or even presented at the Sprint Review. It returns to the Product Backlog for future consideration.
Is partially done work an Increment?: No. Only work that meets the Definition of Done is part of an Increment. Anything else stays in the Product Backlog.
Must an Increment be released every Sprint?: No. An Increment must be usable (potentially releasable), but the Product Owner decides whether and when to actually release it.
Who decides whether to release an Increment?: The Product Owner, who maximizes the value of the product.
Why deliver value in frequent small Increments?: Frequent, small Increments allow earlier feedback, faster learning, reduced risk, and earlier value delivery, supporting empirical control.
Definition of Ready vs. Definition of Done: Definition of Done is part of Scrum (quality of the Increment). 'Ready' is an optional, team-created agreement on when a Product Backlog item is sufficiently understood to be selected — it is not a formal Scrum artifact or commitment.
Are estimates required in Scrum?: Scrum does not prescribe an estimation technique. Items have 'size' added during refinement; the Developers are responsible for sizing.
Is a 'burndown chart' required by Scrum?: No. Burndown/burnup charts are useful complementary practices to track progress but are not mandated by the Scrum Guide.
Single source of work: The Product Backlog is the single source of work undertaken by the Scrum Team. Work not in the Product Backlog should not be undertaken.
Why does quality not decrease during a Sprint?: Lowering quality (e.g., relaxing the Definition of Done) hides debt and reduces the transparency the team needs to inspect and adapt accurately.
Technical debt and the Definition of Done: A rigorous Definition of Done helps prevent the accumulation of technical debt; relaxing it to 'finish' work simply defers and grows the debt.
Value in Scrum: The whole point of a Sprint is a valuable, usable Increment. The Product Owner maximizes the value the team delivers, guided by the Product Goal.
Forecast vs. commitment of scope: The selected Sprint scope is a forecast by the Developers, not a firm promise. The commitment is to the Sprint Goal; scope may be renegotiated as the team learns.
Velocity (complementary practice): An optional measure of how much work a team completes per Sprint, used only by that team to forecast. Velocity is not a Scrum artifact and should not be used to compare teams or as a target.
Why not use velocity as a goal?: Targeting a velocity number incentivizes inflating estimates and cutting quality, undermining transparency. The goal of a Sprint is a 'Done', valuable Increment — not a number.
Scaling Scrum: When multiple Scrum Teams work on one product, they share one Product Goal, one Product Backlog, and one Product Owner. The Scrum Guide itself does not prescribe a scaling framework.
Multiple teams, one product — what is shared?: One Product Owner, one Product Backlog, and one Product Goal, with an integrated Definition of Done so all Increments combine into a usable whole.
Does the Scrum Guide define how to scale?: No. It describes Scrum for one team and notes that larger efforts use multiple cohesive Scrum Teams; specific scaling approaches (e.g., Nexus) are outside the Guide.
Professional Scrum (concept): Scrum.org emphasizes that doing Scrum well requires living the values, true empiricism, technical excellence, and continuous improvement — not just performing the mechanics.
Mechanical Scrum (anti-pattern): Going through Scrum's events and artifacts without embracing the values, transparency, or empiricism. It produces 'fake' agility and little real improvement.
ScrumMaster as a change agent: The Scrum Master helps the wider organization adopt empirical, agile ways of working and removes barriers between stakeholders and Scrum Teams.
Should the Scrum Master remove every impediment personally?: Ideally no. The better long-term outcome is coaching the team and organization to remove impediments themselves, increasing the team's capability.
Continuous improvement in Scrum: Built in via inspection and adaptation — especially the Sprint Retrospective, where the team commits to actionable improvements each Sprint.
When is a team 'doing Scrum'?: Only when it implements Scrum in its entirety — all accountabilities, events, artifacts, and the rules binding them. Partial Scrum is not Scrum.
Empirical process control vs. defined process control: Empirical control suits complex work where outcomes emerge (frequent inspect/adapt); defined control suits repeatable work with predictable outcomes. Scrum uses empirical control.
Why does Scrum favor working product over documentation?: A 'Done', usable Increment is the most transparent measure of progress; it can be inspected directly, unlike plans, status reports, or documentation.
Tailoring Scrum (acceptable vs. not): You may add practices and techniques within Scrum, but you may not remove its defined elements. Dropping an event, accountability, or artifact breaks the framework.
Stakeholder feedback loop: Stakeholders provide feedback chiefly at the Sprint Review, which drives Product Backlog adaptation — closing the empirical loop between the team and the market.
Sustainable pace: Self-managing teams plan realistic Sprint forecasts and protect quality, enabling a sustainable pace rather than overcommitting and burning out.
Why is the Product Goal a long-term anchor?: It gives the Scrum Team a clear objective to plan against across many Sprints; the team focuses on one Product Goal at a time.
Outcome vs. output: Scrum optimizes for valuable outcomes (a useful product) over raw output (features shipped). The Product Owner judges value, not item count.
Definition of Done as a minimum, not a maximum: It defines the minimum quality bar for an Increment; teams are free to apply more rigorous standards but never less than an organizational Definition of Done.
Why is the Increment 'thoroughly verified'?: Verification ensures the new Increment integrates with all prior Increments and actually works together, preserving transparency about the true state of the product.
PSM I assessment — questions and time: 80 questions in 60 minutes.
PSM I passing score: 85% — you must answer at least 68 of 80 questions correctly.
PSM I question formats: Multiple choice, multiple answer, and true/false.
PSM I — does it expire?: No. The PSM I certification is for life — there is no expiration date and no annual renewal fee.
PSM I — what does it certify?: A fundamental level of understanding of the Scrum framework and the ability to support its use as defined in the Scrum Guide 2020.
Which Scrum Guide does PSM I use?: The 2020 edition of the Scrum Guide — the current, normative version. PSM I is updated for Scrum Guide 2020.
PSM I vs. PSM II vs. PSM III: PSM I is the fundamental level, PSM II is the advanced/intermediate level, and PSM III is the distinguished/expert level of Scrum mastery.
Professional Scrum Competencies (Scrum.org): Focus areas Scrum.org uses to describe Scrum mastery: Understanding and Applying the Scrum Framework, Developing People and Teams, and Managing Products with Agility. PSM I centers on the first.
Definition of complex (Cynefin sense): Cause and effect are only clear in hindsight; you must probe, sense, and respond. Scrum is built for complex work, using frequent inspection and adaptation.
Why is Scrum 'lightweight'?: It is purposefully minimal — three accountabilities, five events, three artifacts, and the rules binding them — leaving teams maximum freedom in how they work.
Inspect-and-adapt cadence: Scrum's events create a regular rhythm of inspection and adaptation: planning, daily, review, and retrospective, all inside the Sprint.
What undermines transparency?: Low-quality work, hidden impediments, vague Product Backlog items, and an unclear Definition of Done all reduce transparency and corrupt inspection.
Self-management depends on which values?: Courage and commitment to do the right work, plus openness and respect, enable a team to genuinely self-manage.
Does Scrum guarantee success?: No. Scrum makes the relative efficacy of management, environment, and work techniques visible so the team can continuously improve — it surfaces problems rather than solving them automatically.
Sashimi / 'potentially shippable': An older way of saying each Increment should be usable and meet the Definition of Done; the 2020 Guide uses 'usable Increment'.
Timebox (definition): A maximum allotted duration for an event. Scrum events each have a maximum time-box to prevent waste and create regularity.
A manager wants to assign tasks to individual Developers — is that Scrum?: No. The Developers self-manage and decide internally who does what. The Scrum Master should coach the organization to respect the team's self-management.
A Scrum Master keeps making the team's decisions — what's wrong?: It undermines self-management. The Scrum Master should coach and facilitate, helping the team make its own decisions, not decide for it.
Two people both claim to be Product Owner for one product — what does Scrum say?: There is exactly one Product Owner per product. The organization must clarify a single accountable Product Owner so backlog decisions are respected.
A central team owns a slow access process that blocks the Sprint — whose job?: The Scrum Master works to remove that organizational impediment, ideally by helping the team and organization address it themselves.
Who instills quality into the product?: The Developers, by adhering to a Definition of Done; the whole Scrum Team is accountable for a 'Done' Increment.
Who creates the plan for the Sprint?: The Developers create the Sprint Backlog — the plan for delivering the Increment — by and for themselves.
Can the Product Owner override the team on how work is done?: No. The Product Owner decides what and in what order; the Developers decide how, because the team is self-managing.
Servant leadership (definition): A leadership philosophy where the leader's main goal is to serve — supporting and developing the team and removing obstacles — which the Scrum Master embodies.
Coaching vs. mentoring vs. teaching (Scrum Master stances): Coaching draws answers out of the team, mentoring shares experience, teaching imparts knowledge. A skilled Scrum Master shifts stance to fit the situation.
Facilitation (Scrum Master skill): Helping a group have effective conversations and reach decisions — e.g., enabling productive, time-boxed Scrum events without dominating them.
Should the Scrum Master attend every Daily Scrum?: Not necessarily. The Scrum Master ensures the Daily Scrum happens and stays within 15 minutes; the event belongs to the Developers.
Is 'Scrum Master' a management position over the team?: No. The Scrum Master has no authority over team members; they are a leader who serves the team and organization.
Cross-functional (team property): The team has all the competencies needed, within the team, to create value each Sprint without depending on others outside it.
A bottleneck specialist is overloaded while others idle — what should a cross-functional team do?: Spread skills so more members can do the work (e.g., pairing, learning), increasing cross-functionality and flow rather than relying on one expert.
When does a new Sprint start?: Immediately after the conclusion of the previous Sprint — there are no gaps between Sprints.
Can Sprint length vary Sprint to Sprint?: Scrum favors a consistent Sprint length to create a steady cadence; the team picks a duration of one month or less and keeps it.
During the Sprint, can scope change?: Scope may be clarified and renegotiated with the Product Owner as more is learned — but not in a way that endangers the Sprint Goal.
Who facilitates the Scrum events?: Any Scrum Team member may facilitate; the Scrum Master ensures events take place, are positive and productive, and are kept within their time-box.
The team turns the Sprint Review into a one-way demo — what's the fix?: Make it a working session: collaborate with stakeholders, gather feedback, and adapt the Product Backlog. The review is for inspection and adaptation, not just presenting.
A burndown shows remaining work flattening — what does it signal?: The team is not reducing remaining work; it may be blocked or scope is growing. It's a cue to inspect at the Daily Scrum and adapt the plan.
Why hold the Daily Scrum at the same time and place?: Consistency reduces complexity and decision overhead, making it easier for Developers to inspect progress every day.
Can the Daily Scrum be replaced by a chat-tool update?: The Daily Scrum is an event for the Developers to inspect progress and adapt the plan toward the Sprint Goal; the format is theirs, but it must serve that purpose.
What is the Sprint Review's main output used for?: Adjusting the Product Backlog — the review's collaboration determines the probable next things to work on.
Retrospective output: Improvements the Scrum Team will tackle; the most impactful are often addressed as soon as possible, even added to the next Sprint Backlog.
Why is the Sprint called the 'heartbeat' of Scrum?: Each Sprint produces a usable Increment at a regular cadence, giving the product a steady rhythm of value and feedback.
A Sprint is going badly — can the Scrum Master cancel it?: No. Only the Product Owner can cancel a Sprint, and only when the Sprint Goal becomes obsolete.
Are Scrum events meetings about status reporting?: No. They are formal opportunities to inspect and adapt; status-report-style meetings are an anti-pattern.
Sprint Planning attendees: The whole Scrum Team. Others may be invited by the team for advice, but the team owns the plan.
Where does work the team will do come from?: Only the Product Backlog — it is the single source of work for the Scrum Team.
Order vs. priority in the Product Backlog: The 2020 Guide says the Product Backlog is 'ordered' (not merely prioritized), reflecting value, risk, dependencies, and more, by the Product Owner.
A Product Owner adds every requested feature — what's the risk?: It dilutes value and focus. The Product Owner should order by value and say no to low-value work to maximize the product's value.
Item too large to finish in a Sprint — what do you do?: Refine it: split the Product Backlog item into smaller items that can be 'Done' within a Sprint before selecting it.
A team refines items far down the backlog in big blocks — better approach?: Refine just enough, just in time — focus refinement on near-term items so detail is added when it is most accurate and useful.
Sprint Goal gives the Sprint what?: Coherence and focus — a single objective that unites the Developers' work rather than a set of disconnected tasks.
Mid-Sprint, an item is far larger than thought — what's renegotiated?: Scope, with the Product Owner — the Sprint Goal stays fixed, but which items deliver it can be adjusted.
Increment must be what before it counts?: It must meet the Definition of Done — usable and meeting the required quality measures.
Multiple Increments in one Sprint — allowed?: Yes. The sum of the Increments is presented at the Sprint Review, but an Increment may be delivered to stakeholders before the Sprint ends.
Who can declare an item 'Done'?: It is 'Done' only when it meets the shared Definition of Done — quality is objective, not an individual's opinion.
Product Backlog characteristic: emergent: It is never complete; it evolves as the product and environment change, constantly refined.
Sprint Backlog visibility: It is a highly visible, real-time picture of the Sprint's work, updated by the Developers throughout the Sprint.
What connects all Increments to a direction?: The Product Goal — each Increment is a stepping stone toward it.
Commitment for the Sprint Backlog: The Sprint Goal.
Commitment for the Product Backlog: The Product Goal.
Commitment for the Increment: The Definition of Done.
A team relaxes its Definition of Done to 'finish' — consequence?: It creates undone work and technical debt, reduces transparency, and risks an unusable product. Quality must not decrease.
Manager compares two teams' velocities — why is that wrong?: Velocity is team-specific and not comparable across teams; using it to compare or target distorts behavior and is not a Scrum measure.
Multiple teams on one product share a Definition of Done — why?: A common (integrated) Definition of Done ensures all teams' Increments combine into a single usable product.
Is 'release every Sprint' required?: No — but the Increment must be releasable. Whether to release is the Product Owner's decision.
Empirical control reduces risk how?: By limiting each Sprint's investment to a short period and inspecting real results frequently, so course corrections happen early and cheaply.
Why prefer outcomes over output?: Shipping many features ('output') is worthless if they don't deliver value ('outcomes'); the Product Owner optimizes for value.
Sustainable pace and self-management: Self-managing teams forecast realistically and protect quality, avoiding overcommitment and enabling a pace they can maintain indefinitely.
A formal, fixed long-term release plan made fully up front — Scrum's view?: Scrum favors adaptive planning; long-term plans are forecasts that change as empirical evidence accrues, not fixed commitments.
Definition of Done changes mid-product — effect?: If the Definition of Done expands, past Increments may need rework; teams keep it stable and improve it deliberately.
Who removes barriers between stakeholders and the team?: The Scrum Master, as part of serving the organization.
What does 'doing Scrum' require to be real?: Living the Scrum Values and true empiricism — not just performing the events and producing the artifacts mechanically.
Why is a 'Done' Increment the best progress measure?: It is working product that can be inspected directly, giving honest transparency unlike plans, reports, or hours spent.
Scrum and continuous improvement: Inspection and adaptation — especially the Retrospective — make improvement a built-in, every-Sprint habit.
One Product Goal at a time: A Scrum Team should fulfill (or abandon) its current Product Goal before taking on the next, to keep focus.
Nexus (context): A framework from Scrum.org for scaling Scrum to multiple teams on one product. It is built on Scrum but is not part of the Scrum Guide itself.
Product Backlog item (PBI): A single entry in the Product Backlog — a feature, function, requirement, enhancement, or fix needed to improve the product.
Refinement (one line): Ongoing breaking down and detailing of Product Backlog items so they become ready for selection.
Sprint Backlog (one line): Sprint Goal + selected items + the plan to deliver them; owned by the Developers.
Product Backlog (one line): The single, ordered, emergent source of work for the product, owned by the Product Owner.
Increment (one line): A usable, 'Done' stepping stone toward the Product Goal, additive to all prior Increments.
Definition of Done (one line): The shared quality bar an Increment must meet to be considered complete.
Product Goal (one line): The long-term objective describing a future state of the product.
Sprint Goal (one line): The single objective for one Sprint that gives the work coherence.
Scrum Master (one line): Accountable for Scrum being understood and enacted, and for the team's effectiveness; a servant leader.
Product Owner (one line): Accountable for maximizing product value and managing the Product Backlog; one person.
Developers (one line): Team members committed to creating a usable Increment each Sprint; self-managing and cross-functional.
Scrum Team (one line): One cohesive unit of a Scrum Master, a Product Owner, and Developers — no sub-teams.
Sprint (one line): A one-month-or-less container event in which a usable Increment is created.
Sprint Planning (one line): Starts the Sprint; the team plans why it's valuable, what can be Done, and how. Max 8 hrs.
Daily Scrum (one line): A 15-minute daily event for the Developers to inspect and adapt toward the Sprint Goal.
Sprint Review (one line): End-of-Sprint working session with stakeholders to inspect the Increment and adapt the backlog. Max 4 hrs.
Sprint Retrospective (one line): Closes the Sprint; the team plans improvements to quality and effectiveness. Max 3 hrs.
Empiricism (one line): Knowledge from experience; decisions based on what is observed.
Transparency / Inspection / Adaptation: The three pillars of Scrum's empirical process.
Commitment / Focus / Openness / Respect / Courage: The five Scrum Values.
Self-managing (one line): The team decides who does the work, and when and how, internally.
Cross-functional (one line): The team has all skills needed to create value each Sprint, with no external dependency.
Usable Increment (one line): An Increment that meets the Definition of Done and could be put to use.
Time-box (one line): A maximum allowed duration for an event.
Stakeholder (one line): Anyone outside the Scrum Team with an interest in the product; gives feedback at the Review.

To find us again, just search “Career Employer PSM”

By Career EmployerUpdated Jun 19, 2026

200+ free PSM I flashcards — 4 ways to study

PSM I Flashcard of the DayNew daily

The classic card. Do you know this one?

Click Study Flashcards above to open the flashcard hub — hundreds of PSM I cards you can flip, match, type, or quiz yourself on. Every card is drawn straight from the Scrum Guide 2020, so you study exactly what the assessment tests.^[1] Pair them with our free practice test and study guide.

PSM I Flashcard Study Modes

Most flashcard sites give you one thing: a card to flip. Ours has four modes so you can both learn the material and prove you know it — the difference between recognizing an answer and recalling it under exam pressure.

Flip (Study) — the classic card. Flip term ↔ definition, shuffle the deck, and mark each card “Got it” or “Still learning.”
Match (Game) — a timed game: pair each term to its definition as fast as you can. Great for cementing time-boxes and the artifact commitments.
Type (Recall) — read the definition and type the term. Typing forces true active recall instead of passive recognition.
Quiz (Test) — multiple-choice questions generated from the cards, so you self-test exactly like assessment day.

Free PSM I flashcards from Career Employer — active recall for the Professional Scrum Master I assessment

Why Flashcards Work for the PSM I

Flashcards aren’t busywork — they’re built on active recall: pulling an answer out of memory strengthens it far more than re-reading notes. Pair that with spacing — short sessions across several days rather than one cram — and you retain more in less time.

The PSM I is dense with precise terminology — the five events and their time-boxes, the three accountabilities, the three artifacts and their commitments, and the Definition of Done.^[1] Spaced flashcards are the most efficient way to keep it all fresh for an 85%, 60-minute assessment. Used alongside our practice test and study guide, they turn review time into measurable progress.

PSM I Flashcards by Topic

The cards are organized to the Scrum Guide 2020. Lock down the facts (time-boxes, accountabilities, and the artifact commitments) first, then test your judgment on applying Scrum:^[1]

PSM I flashcards by topic
Deck	What it covers
Scrum Theory & Values	Empiricism, the three pillars, the five Scrum Values
Accountabilities	Scrum Master, Product Owner, Developers, and the Scrum Team
Events	The Sprint + Planning, Daily Scrum, Review, Retrospective (and time-boxes)
Artifacts & Commitments	Product/Sprint Backlog, Increment + Product Goal/Sprint Goal/Definition of Done
Done, Value & Scaling	Definition of Done, value & forecasting, applying and scaling Scrum

How to Get the Most Out of These Flashcards

Burn in the time-boxes. Planning 8h, Daily 15min, Review 4h, Retro 3h — these are free points you can’t miss.
Pair every artifact with its commitment. Product Backlog → Product Goal, Sprint Backlog → Sprint Goal, Increment → Definition of Done.
Use Type and Quiz, not just Flip. Recognizing the right answer is easy; recalling and choosing it under a clock is the real test.
Drill your weakest deck. Pick one topic and grind it until the Match time drops and the Quiz score climbs.
Then prove it. When the cards feel easy, confirm with a full practice test — aim comfortably above 85% before assessment day.

PSM I Flashcards FAQ

Hundreds of free PSM I flashcards, organized across the Scrum Guide 2020 — Scrum theory and values, the accountabilities, the events, the artifacts and commitments, and Done/value/scaling. They're free with no account required.

References

1.Ken Schwaber & Jeff Sutherland. “The 2020 Scrum Guide.” scrumguides.org. ↑
2.Scrum.org. “Professional Scrum Master I (PSM I) Certification.” scrum.org. ↑
3.Scrum.org. “Professional Scrum Competencies: Understanding and Applying the Scrum Framework.” scrum.org. ↑

Career Employer

Career Employer is the ultimate resource to help you get started working the job of your dreams. We cover topics from general career information, career searching, exam preparation with free study materials, career interviewing, and becoming successful in your career of choice.

All Posts

Career Employer’s Editorial Process

Here at Career Employer, we focus a lot on providing factually accurate information that is always up to date. We strive to provide correct information using strict editorial processes, article editing, and fact-checking for all of the information found on our website. We only utilize trustworthy and relevant resources. To find out more, make sure to read our full editorial process page here.