PSM key terms

The practice of basing decisions on what is observed and measured rather than on assumption or prediction. It rests on transparency, inspection, and adaptation so that teams adjust course as real evidence arrives.

Making the state of the work and its artifacts visible to everyone accountable for it. Without a shared, honest view of reality, inspection produces misleading conclusions and adaptation goes in the wrong direction.

Frequent, purposeful examination of artifacts and progress toward goals. Inspection is only useful when the thing inspected is transparent and the inspector has the skill and authority to interpret what they find.

Adjusting process, product, or plan as soon as inspection reveals a deviation or a better option. Delaying adaptation increases waste, so Scrum builds explicit moments for it into its events.

Commitment, Focus, Openness, Respect, and Courage. They describe how people behave when working in Scrum and give concrete direction when a team must choose between comfortable and effective action.

A small, cross-functional group of up to ten people made of one Scrum Master, one Product Owner, and Developers. It holds all skills needed to deliver value and is collectively accountable for its outcomes.

The Scrum Team members who create the product increment, own the Sprint Backlog, and self-manage their daily work. The term covers anyone doing the hands-on work, whatever their specialist title.

The single person accountable for maximizing product value, owning the Product Backlog, and defining product goals. They make ordering decisions visible and are the primary voice for what gets built next.

A true leader who serves the team and the wider organization by teaching Scrum, removing impediments, and fostering self-management. They coach rather than direct, and they are accountable for Scrum being used effectively.

A fixed-length iteration of one month or less in which a usable increment is created. It is the container for all other Scrum events and shortens the feedback loop between idea and evidence.

The event that opens a Sprint, where the team agrees why the Sprint is valuable, what can be done, and how the work will get done. It produces the Sprint Goal and the Sprint Backlog.

A single objective for the Sprint that gives the team focus and coherence, even though individual backlog items may change. It is committed to by the whole Scrum Team and is a tool for self-management.

A fifteen-minute event for Developers to inspect progress toward the Sprint Goal and adapt the plan for the next day. It is a working session, not a status report to a manager.

The second-to-last event of a Sprint, where the team and stakeholders inspect the increment against the Product Goal and decide what to do next. It is a working session, not a demo or sign-off gate.

The closing event of a Sprint, where the team inspects how it worked and identifies the most useful improvements. Concrete actions are chosen and, ideally, addressed within the next Sprint.

An emergent, ordered list of everything that might build product value. It is the single source of work for the Scrum Team and is refined continuously rather than written once and frozen.

The Sprint Goal, the items selected for the Sprint, and the Developers' plan for delivering them. It is a living picture of work that the Developers update daily as they learn.

The concrete, usable step toward the Product Goal produced during a Sprint. Each increment adds to previous ones and must meet the Definition of Done before it counts.

A shared, explicit checklist describing what it means for work to be complete. It makes quality transparent, prevents unfinished work from being counted, and is applied to every increment.

A long-term, measurable objective describing the future state of the product the team is working toward. It gives the Product Backlog direction and connects daily work to real product value.

A team that decides internally who does what, when, and how, rather than receiving those decisions from outside. Self-management grows through clear boundaries, trust, and deliberate practice.

A team holding all the skills needed to deliver a working product without depending on outside groups for core work. Cross-functionality shortens feedback loops and reduces handoffs and waiting.

Designing and guiding group work so that participants reach decisions and shared understanding themselves. A facilitator manages process, not content, and stays neutral on the substance being discussed.

Helping people improve through questions, observation, and reflection rather than instructions. Coaching assumes the coachee is capable and aims at durable capability, not a one-time fix.

Sharing expertise and advice to help someone build specific skills, often from a more experienced practitioner. It differs from coaching because the mentor contributes knowledge and direction directly.

Any obstacle slowing the team that it cannot remove on its own, such as missing access, unclear policy, or a broken dependency. Surfacing and removing impediments is a core service of the Scrum Master.

A set of simple, repeatable facilitation formats that distribute participation instead of centering it on one speaker. Examples include 1-2-4-All and Troika Consulting, useful in retrospectives and workshops.

Estimating what is likely to be delivered by a given date using observed data such as throughput and cycle time, with explicit uncertainty. A forecast is a probability statement, not a promise.

The average amount of backlog work a team completes per Sprint, measured in a consistent unit. It is a short-term planning aid for that team only, never a performance target or a cross-team comparison.

The number of work items completed in a period, regardless of their size. Combined with cycle-time data it supports probabilistic forecasts such as how many items are likely done by a date.

The elapsed time from when work on an item starts to when it is finished. Tracking it reveals bottlenecks and lets teams predict delivery dates without relying on effort estimates alone.

A lightweight, revisable view of which increments will reach users and roughly when. It should be driven by value and learning rather than fixed scope, and updated as evidence accumulates.

The ongoing work of ordering items by value, refining them, and keeping the backlog transparent and current. It includes deciding what to drop as much as what to add.

The continuous activity of breaking down, clarifying, and re-ordering backlog items so they are ready for upcoming Sprints. It is a shared team activity, not a private task of the Product Owner.

The benefit a product delivers to customers and the organization, such as revenue, reduced risk, or capability gained. Value is judged by outcomes, not by the quantity of features shipped.

A measurable change in behavior or results that a product produces for its users or business. Outcomes are distinguished from outputs, which are merely the features and deliverables created.

People outside the Scrum Team who have an interest in the product, such as customers, users, sponsors, and support staff. Their needs inform the backlog and are engaged mainly through the Product Owner and Sprint Review.

The smallest version of a product that lets a team test key assumptions with real users and learn quickly. Its purpose is validated learning, not a low-quality release.