CSO (Other exams) key terms

The belief that knowledge comes from experience and from making decisions based on what is actually observed. Scrum applies it through transparency, inspection, and adaptation so teams learn by doing rather than by predicting everything up front.

A state in which the process, its work, and the resulting artifacts are visible to everyone accountable for the outcome. Without it, inspection misleads and adaptation produces worse results instead of better ones.

Frequent, deliberate examination of Scrum artifacts and progress toward goals, performed by skilled people at the events designed for it. It is the middle step of empiricism and only works when the thing inspected is genuinely transparent.

Adjusting the process, product, or plans as soon as inspection reveals a deviation or a better option. It is the outcome empiricism aims for, and it is deliberately built into the Sprint through events and artifact updates.

A mindset that reduces waste, limits work in progress, delays commitment until the last responsible moment, and delivers value in small increments. It underpins Scrum practices such as timeboxing and keeping the Sprint Backlog focused.

Commitment, Focus, Openness, Respect, and Courage. They are not a checklist but the behavioral standard that makes the framework work; teams assess how well they live these values rather than whether they merely recite them.

A small, cross-functional group of up to ten people consisting of one Scrum Master, one Product Owner, and Developers. It is collectively accountable for the product and holds all skills needed to deliver a usable increment every Sprint.

The single person accountable for maximizing product value, owning the Product Backlog, and setting the Product Goal. They may delegate work but never the accountability, and they must be empowered to make product decisions.

A servant leader accountable for the team's effectiveness and for establishing Scrum as described in the framework. They coach the team and the wider organization, facilitate events, and remove impediments rather than direct day-to-day work.

The members of the Scrum Team who create the usable increment each Sprint. They self-manage their work, own the Sprint Backlog, and hold all technical skills needed to build a Done product.

A team that decides internally who does what, when, and how, rather than receiving those instructions from outside. It still works within agreed goals and constraints, but chooses its own approach to meeting them.

A property of the Scrum Team meaning it collectively possesses every skill needed to deliver value, so it need not depend on outside groups each Sprint. It describes the team as a whole, not each individual.

A fixed-length iteration, typically one to four weeks, in which the team turns backlog items into a usable increment. It is the container for all other Scrum events and protects the team from disruptive change mid-iteration.

The first event of the Sprint, where the team agrees why the Sprint matters, what can be delivered, and how the work will get done. It produces the Sprint Goal and the Sprint Backlog.

A short daily event, timeboxed to fifteen minutes, where Developers inspect progress toward the Sprint Goal and adjust their plan. It is for the Developers, not a status report for managers.

An event near the end of the Sprint where the team and stakeholders inspect the increment and adapt the Product Backlog. It is a working session about the product, not a formal presentation or sign-off gate.

The closing event where the team inspects how it worked and identifies improvements to its process and behavior. It focuses on people, interactions, and practices rather than on the product itself.

A fixed maximum duration for an event that is not extended to finish discussion. Timeboxing creates focus and forces prioritization, and unused time is simply lost rather than banked.

An ordered, ever-evolving list of everything that might improve the product, with the most valuable items at the top. The Product Owner owns it, and it is never complete while the product exists.

A plan made up of the Sprint Goal, the selected backlog items, and the developers' plan for delivering the increment. It is owned by the Developers and updated daily as understanding improves.

The concrete, usable step toward the Product Goal produced each Sprint. It must meet the Definition of Done, and multiple increments may be created within a single Sprint.

A shared commitment describing what it means for work to be complete and releasable. The team creates it, applies it to every increment, and tightens it over time rather than loosening it to fit deadlines.

A long-term, measurable objective describing the future state of the product that the backlog serves. It gives the team a destination and a reason to order work, and it is replaced only when achieved or abandoned.

A single objective for the Sprint that gives the team focus and coherence beyond the sum of selected items. It is created during planning and may be renegotiated with the Product Owner as new information emerges.

The ongoing activity of breaking down, clarifying, and re-ordering backlog items so they are ready for future Sprints. It is not a formal Scrum event and its timing and format are chosen by the team.

A leadership stance in which the Scrum Master focuses on the needs and growth of others, removing obstacles and building capability rather than issuing orders. Authority is used to enable, not to control.

Designing and guiding group interactions so participants can reach decisions and outcomes themselves. A skilled facilitator stays neutral on content, manages the process, and avoids imposing their own answer.

Any obstacle that slows or blocks the team's progress toward its goals, such as missing access, unclear decisions, or dependencies on other groups. The Scrum Master helps ensure impediments are surfaced and resolved.

Helping people grow by asking powerful questions, reflecting back observations, and letting them find their own answers. It differs from mentoring and consulting, which supply expertise or solutions directly.

Sharing experience and expert guidance to help someone develop skills more quickly than they would alone. It is useful when a team lacks knowledge of Scrum or engineering practice, but it risks creating dependency if overused.

The habit of making small, regular changes to process and product based on evidence rather than waiting for a large transformation. In Scrum it is driven mainly through the retrospective and the adaptation of artifacts.

A Japanese term for small, ongoing improvements made by the people doing the work, rather than large top-down change programs. It aligns closely with the retrospective's focus on incremental, owned improvement.

The pattern groups follow from forming through storming and norming to performing. Recognizing the stage helps a Scrum Master adjust support, giving more direction early and more autonomy later.

Applying Scrum across many teams while preserving the framework's core so coordination does not smother empiricism. Approaches vary, but all must keep teams self-managing and integrate work into a single usable product.

A framework for scaling Scrum across multiple teams working on one product, adding an integration team and a shared backlog. It keeps a single Product Owner and a single Definition of Done across all teams.

A relationship in which one team's work must wait for another team's output. Dependencies are normal but should be made visible and minimized, since they add delay and coordination cost at scale.

An organization's ability to sense change and respond quickly, supported by structures, policies, and leadership that allow teams to self-manage. Scrum teams cannot sustain agility inside an organization that punishes empiricism.