Professional Scrum Master I (PSM I) key terms

The belief that knowledge comes from experience and from decisions based on what is actually observed, rather than on theory or prediction alone. Scrum applies it through transparency, inspection, and adaptation.

A state in which the process, its work, and its results are visible to the people who need to see them, so that inspection reveals real problems instead of hidden ones.

The frequent, careful examination of Scrum artifacts and progress toward goals, carried out by skilled people using agreed standards, so that problems are detected early.

Adjusting the process or the product as soon as an inspection shows that something is off-track or is producing an unacceptable result.

A condition with many interacting parts and unpredictable outcomes, where cause and effect are clear only in hindsight; Scrum is built for this kind of work.

Commitment, focus, openness, respect, and courage: five behavioral expectations that guide how Scrum Team members work together and treat each other and their stakeholders.

Building a product through repeated short cycles while adding usable pieces of functionality each cycle, so that learning and value arrive early and often.

A way of working that aims to reduce waste, limit work in progress, and keep attention on what delivers value, shaping Scrum's short cycles and focus on essentials.

A small, cohesive group of ten or fewer people made up of one Product Owner, one Scrum Master, and Developers, collectively responsible for delivering a valuable, usable Increment each Sprint.

The single accountable person for maximizing product value, who develops and communicates the Product Goal, orders the Product Backlog, and decides which work is worth doing.

The Scrum Team members who create the usable Increment each Sprint, self-manage their daily work, and hold all the skills needed to turn backlog items into Done work.

The accountable person for establishing Scrum as defined in the Scrum Guide and for helping the team and organization improve their use of it through teaching, coaching, and removing impediments.

A team that decides internally who does what, when, and how, rather than being directed by a manager or by the Scrum Master.

A team holding all the skills necessary to create value independently, so it does not depend on people outside the team to finish an Increment.

A blocker or obstacle that slows or stops the team's progress and that the Scrum Master helps to remove. It may sit inside the team or in the wider organization.

A long-term target describing a future state of the product that gives the Product Backlog direction; it is the commitment attached to the Product Backlog.

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

The ongoing activity of breaking down and clarifying Product Backlog items so they are small and understood well enough to be selected in Sprint Planning; the team decides how much time to spend.

A single entry in the Product Backlog, such as a feature, fix, or improvement. Items carry a description, an order, and often an estimate, and become Sprint work when selected.

A single objective for the Sprint that gives the team a shared focus and flexibility; it is the commitment attached to the Sprint Backlog and is met through the items selected.

The set of Product Backlog items selected for the Sprint plus the plan for delivering them. It is created in Sprint Planning and updated by the Developers as they learn.

The concrete, usable step toward the Product Goal produced during a Sprint. Each Increment adds to earlier ones and must meet the Definition of Done to count as complete.

A shared, explicit checklist of the quality standards work must meet before it counts as complete; it is the commitment attached to the Increment.

The value or standard attached to each Scrum artifact, namely the Product Goal, Sprint Goal, and Definition of Done, used to check progress and keep work focused.

A fixed-length cycle of one month or less in which the Scrum Team turns selected work into a usable Increment; every other Scrum event happens inside it.

The event that starts the Sprint, where the team agrees why the Sprint is valuable, what can be done in it, and how the chosen work will be carried out.

A 15-minute event for the Developers, held every working day, to inspect progress toward the Sprint Goal and adjust the Sprint Backlog plan for the next day.

The second-to-last event of the Sprint, where the team and stakeholders inspect the Increment and the Product Backlog together and adapt what happens next.

The final event of the Sprint, where the team inspects how it worked and identifies the most useful improvements to apply in the next Sprint.

A maximum duration set for a Scrum event so it stays focused; if the event's purpose is achieved earlier, it can end sooner.

The team's realistic expectation, formed during Sprint Planning, about what it can deliver in the Sprint based on its capacity and on what it has learned so far.

Ending a Sprint before its timebox expires. Only the Product Owner may do this, and only when the Sprint Goal becomes obsolete; finished work is reviewed and the rest returns to the backlog.

The lightweight structure of accountabilities, events, artifacts, and rules described in the Scrum Guide; it is deliberately incomplete, leaving specific practices to the team.

Working closely with customers, users, and others affected by the product so their needs inform the Product Backlog and are examined at each Sprint Review.

Changing structures, policies, and habits across an organization so Scrum Teams can genuinely self-manage and deliver value, often guided by the Scrum Master.