Your FREE PSM I Flashcards 2026 – 200+ Cards

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.

Transparency, Inspection, and Adaptation.

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.

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

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.

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

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

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.

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

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

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.

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.

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.

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.

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

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.

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

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.

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

80 questions in 60 minutes.

85% — you must answer at least 68 of 80 questions correctly.

Multiple choice, multiple answer, and true/false.

No. The PSM I certification is for life — there is no expiration date and no annual renewal fee.

A fundamental level of understanding of the Scrum framework and the ability to support its use as defined in the Scrum Guide 2020.

The 2020 edition of the Scrum Guide — the current, normative version. PSM I is updated for Scrum Guide 2020.

PSM I is the fundamental level, PSM II is the advanced/intermediate level, and PSM III is the distinguished/expert level of Scrum mastery.

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.

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.

It is purposefully minimal — three accountabilities, five events, three artifacts, and the rules binding them — leaving teams maximum freedom in how they work.

Scrum's events create a regular rhythm of inspection and adaptation: planning, daily, review, and retrospective, all inside the Sprint.

Low-quality work, hidden impediments, vague Product Backlog items, and an unclear Definition of Done all reduce transparency and corrupt inspection.

Courage and commitment to do the right work, plus openness and respect, enable a team to genuinely self-manage.

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.

An older way of saying each Increment should be usable and meet the Definition of Done; the 2020 Guide uses 'usable Increment'.

A maximum allotted duration for an event. Scrum events each have a maximum time-box to prevent waste and create regularity.

Knowledge from experience; decisions based on what is observed.

The three pillars of Scrum's empirical process.

The five Scrum Values.

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.

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.

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

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.

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.

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

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.

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

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

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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.

No. The Developers self-manage and decide who does what. A Scrum Master assigning work undermines self-management.

The Scrum Master steps back, intervening less, and shifts toward coaching and organizational improvement — the goal is a team that can sustain itself.

The entire Scrum Team is accountable for creating a 'Done', usable Increment; the Definition of Done makes quality everyone's responsibility, not just testers'.

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.

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.

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).

Collective accountability fosters shared ownership and collaboration toward the Sprint Goal, rather than siloed individual outputs.

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.

It undermines self-management. The Scrum Master should coach and facilitate, helping the team make its own decisions, not decide for it.

There is exactly one Product Owner per product. The organization must clarify a single accountable Product Owner so backlog decisions are respected.

The Scrum Master works to remove that organizational impediment, ideally by helping the team and organization address it themselves.

The Developers, by adhering to a Definition of Done; the whole Scrum Team is accountable for a 'Done' Increment.

The Developers create the Sprint Backlog — the plan for delivering the Increment — by and for themselves.

No. The Product Owner decides what and in what order; the Developers decide how, because the team is self-managing.

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 draws answers out of the team, mentoring shares experience, teaching imparts knowledge. A skilled Scrum Master shifts stance to fit the situation.

Helping a group have effective conversations and reach decisions — e.g., enabling productive, time-boxed Scrum events without dominating them.

Not necessarily. The Scrum Master ensures the Daily Scrum happens and stays within 15 minutes; the event belongs to the Developers.

No. The Scrum Master has no authority over team members; they are a leader who serves the team and organization.

The team has all the competencies needed, within the team, to create value each Sprint without depending on others outside it.

Spread skills so more members can do the work (e.g., pairing, learning), increasing cross-functionality and flow rather than relying on one expert.

Accountable for Scrum being understood and enacted, and for the team's effectiveness; a servant leader.

Accountable for maximizing product value and managing the Product Backlog; one person.

Team members committed to creating a usable Increment each Sprint; self-managing and cross-functional.

One cohesive unit of a Scrum Master, a Product Owner, and Developers — no sub-teams.

The team decides who does the work, and when and how, internally.

The team has all skills needed to create value each Sprint, with no external dependency.

Anyone outside the Scrum Team with an interest in the product; gives feedback at the Review.

The Sprint (a container for all others), Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective.

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.

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.

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.

Short Sprints limit cost and risk to one calendar period, enable more frequent inspection and adaptation, and produce learning faster.

Only the Product Owner can cancel a Sprint.

When the Sprint Goal becomes obsolete — e.g., the company changes direction or market/technology conditions change. Cancellations are rare because Sprints are short.

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.

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).

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.

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.

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.

Maximum 8 hours for a one-month Sprint; usually shorter for shorter Sprints.

The Sprint Goal, the Product Backlog items selected for the Sprint, and the plan for delivering them — together, the Sprint Backlog.

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.

15 minutes, every working day of the Sprint, at the same time and place to reduce complexity.

The Developers. If the Product Owner or Scrum Master are actively working on Sprint Backlog items, they participate as Developers.

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.

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.

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.

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.

Maximum 4 hours for a one-month Sprint; shorter for shorter Sprints.

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.

The Scrum Team and key stakeholders invited by the Product Owner. Stakeholder feedback is the main reason to hold it.

A revised Product Backlog that defines the probable next items. The Product Backlog may be adjusted to meet new opportunities.

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.

Maximum 3 hours for a one-month Sprint; shorter for shorter Sprints.

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.

The whole Scrum Team — Scrum Master, Product Owner, and Developers — inspecting how they worked together.

Sprint Planning starts the Sprint; the Daily Scrum happens each day; the Sprint Review and then the Sprint Retrospective close the Sprint.

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.

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.

Yes. The Sprint is a container event that holds all other Scrum events; they all occur within it.

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.

Immediately after the conclusion of the previous Sprint — there are no gaps between Sprints.

Scrum favors a consistent Sprint length to create a steady cadence; the team picks a duration of one month or less and keeps it.

Scope may be clarified and renegotiated with the Product Owner as more is learned — but not in a way that endangers the Sprint Goal.

Any Scrum Team member may facilitate; the Scrum Master ensures events take place, are positive and productive, and are kept within their time-box.

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.

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.

Consistency reduces complexity and decision overhead, making it easier for Developers to inspect progress every day.

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.

Adjusting the Product Backlog — the review's collaboration determines the probable next things to work on.

Improvements the Scrum Team will tackle; the most impactful are often addressed as soon as possible, even added to the next Sprint Backlog.

Each Sprint produces a usable Increment at a regular cadence, giving the product a steady rhythm of value and feedback.

No. Only the Product Owner can cancel a Sprint, and only when the Sprint Goal becomes obsolete.

No. They are formal opportunities to inspect and adapt; status-report-style meetings are an anti-pattern.

The whole Scrum Team. Others may be invited by the team for advice, but the team owns the plan.

A one-month-or-less container event in which a usable Increment is created.

Starts the Sprint; the team plans why it's valuable, what can be Done, and how. Max 8 hrs.

A 15-minute daily event for the Developers to inspect and adapt toward the Sprint Goal.

End-of-Sprint working session with stakeholders to inspect the Increment and adapt the backlog. Max 4 hrs.

Closes the Sprint; the team plans improvements to quality and effectiveness. Max 3 hrs.

A maximum allowed duration for an event.

The Product Backlog, the Sprint Backlog, and the Increment. Each represents work or value and is designed to maximize transparency.

Product Backlog → Product Goal; Sprint Backlog → Sprint Goal; Increment → Definition of Done. Commitments reinforce empiricism and the Scrum Values.

Each commitment provides information that enhances transparency and focus, against which progress can be measured.

An emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

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.

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.

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.

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.

The Product Owner. Ordering reflects value, risk, dependencies, and other factors so the most valuable work is done first.

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.

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.

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.

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.

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.

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.

Each Increment adds to and works with all previous Increments; together they form a coherent, usable product, verified to function as a whole.

Multiple Increments may be created within a Sprint. An Increment is born the moment a Product Backlog item meets the Definition of Done.

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.

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.

It cannot be released or even presented at the Sprint Review. It returns to the Product Backlog for future consideration.

No. Only work that meets the Definition of Done is part of an Increment. Anything else stays in the Product Backlog.

No. An Increment must be usable (potentially releasable), but the Product Owner decides whether and when to actually release it.

The Product Owner, who maximizes the value of the product.

Frequent, small Increments allow earlier feedback, faster learning, reduced risk, and earlier value delivery, supporting empirical control.

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.

Scrum does not prescribe an estimation technique. Items have 'size' added during refinement; the Developers are responsible for sizing.

No. Burndown/burnup charts are useful complementary practices to track progress but are not mandated by the Scrum Guide.

The Product Backlog is the single source of work undertaken by the Scrum Team. Work not in the Product Backlog should not be undertaken.

Only the Product Backlog — it is the single source of work for the Scrum Team.

The 2020 Guide says the Product Backlog is 'ordered' (not merely prioritized), reflecting value, risk, dependencies, and more, by the Product Owner.

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.

Refine it: split the Product Backlog item into smaller items that can be 'Done' within a Sprint before selecting it.

Refine just enough, just in time — focus refinement on near-term items so detail is added when it is most accurate and useful.

Coherence and focus — a single objective that unites the Developers' work rather than a set of disconnected tasks.

Scope, with the Product Owner — the Sprint Goal stays fixed, but which items deliver it can be adjusted.

It must meet the Definition of Done — usable and meeting the required quality measures.

Yes. The sum of the Increments is presented at the Sprint Review, but an Increment may be delivered to stakeholders before the Sprint ends.

It is 'Done' only when it meets the shared Definition of Done — quality is objective, not an individual's opinion.

It is never complete; it evolves as the product and environment change, constantly refined.

It is a highly visible, real-time picture of the Sprint's work, updated by the Developers throughout the Sprint.

The Product Goal — each Increment is a stepping stone toward it.

The Sprint Goal.

The Product Goal.

The Definition of Done.

A single entry in the Product Backlog — a feature, function, requirement, enhancement, or fix needed to improve the product.

Ongoing breaking down and detailing of Product Backlog items so they become ready for selection.

Sprint Goal + selected items + the plan to deliver them; owned by the Developers.

The single, ordered, emergent source of work for the product, owned by the Product Owner.

A usable, 'Done' stepping stone toward the Product Goal, additive to all prior Increments.

The shared quality bar an Increment must meet to be considered complete.

The long-term objective describing a future state of the product.

The single objective for one Sprint that gives the work coherence.

Lowering quality (e.g., relaxing the Definition of Done) hides debt and reduces the transparency the team needs to inspect and adapt accurately.

A rigorous Definition of Done helps prevent the accumulation of technical debt; relaxing it to 'finish' work simply defers and grows the debt.

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.

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.

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.

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.

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.

One Product Owner, one Product Backlog, and one Product Goal, with an integrated Definition of Done so all Increments combine into a usable whole.

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.

Scrum.org emphasizes that doing Scrum well requires living the values, true empiricism, technical excellence, and continuous improvement — not just performing the mechanics.

Going through Scrum's events and artifacts without embracing the values, transparency, or empiricism. It produces 'fake' agility and little real improvement.

The Scrum Master helps the wider organization adopt empirical, agile ways of working and removes barriers between stakeholders and Scrum Teams.

Ideally no. The better long-term outcome is coaching the team and organization to remove impediments themselves, increasing the team's capability.

Built in via inspection and adaptation — especially the Sprint Retrospective, where the team commits to actionable improvements each Sprint.

Only when it implements Scrum in its entirety — all accountabilities, events, artifacts, and the rules binding them. Partial Scrum is not Scrum.

Empirical control suits complex work where outcomes emerge (frequent inspect/adapt); defined control suits repeatable work with predictable outcomes. Scrum uses empirical control.

A 'Done', usable Increment is the most transparent measure of progress; it can be inspected directly, unlike plans, status reports, or documentation.

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.

Stakeholders provide feedback chiefly at the Sprint Review, which drives Product Backlog adaptation — closing the empirical loop between the team and the market.

Self-managing teams plan realistic Sprint forecasts and protect quality, enabling a sustainable pace rather than overcommitting and burning out.

It gives the Scrum Team a clear objective to plan against across many Sprints; the team focuses on one Product Goal at a time.

Scrum optimizes for valuable outcomes (a useful product) over raw output (features shipped). The Product Owner judges value, not item count.

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.

Verification ensures the new Increment integrates with all prior Increments and actually works together, preserving transparency about the true state of the product.

It creates undone work and technical debt, reduces transparency, and risks an unusable product. Quality must not decrease.

Velocity is team-specific and not comparable across teams; using it to compare or target distorts behavior and is not a Scrum measure.

A common (integrated) Definition of Done ensures all teams' Increments combine into a single usable product.

No — but the Increment must be releasable. Whether to release is the Product Owner's decision.

By limiting each Sprint's investment to a short period and inspecting real results frequently, so course corrections happen early and cheaply.

Shipping many features ('output') is worthless if they don't deliver value ('outcomes'); the Product Owner optimizes for value.

Self-managing teams forecast realistically and protect quality, avoiding overcommitment and enabling a pace they can maintain indefinitely.

Scrum favors adaptive planning; long-term plans are forecasts that change as empirical evidence accrues, not fixed commitments.

If the Definition of Done expands, past Increments may need rework; teams keep it stable and improve it deliberately.

The Scrum Master, as part of serving the organization.

Living the Scrum Values and true empiricism — not just performing the events and producing the artifacts mechanically.

It is working product that can be inspected directly, giving honest transparency unlike plans, reports, or hours spent.

Inspection and adaptation — especially the Retrospective — make improvement a built-in, every-Sprint habit.

A Scrum Team should fulfill (or abandon) its current Product Goal before taking on the next, to keep focus.

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.

An Increment that meets the Definition of Done and could be put to use.