CSPO key terms

The Agile principle that knowledge comes from experience and decisions are based on what is observed. Scrum applies it through transparency, inspection, and adaptation so the team can adjust based on real evidence rather than assumptions.

A Scrum pillar requiring that the process, backlog, and product state be visible and understood by everyone accountable for the outcome. Without shared visibility, inspection produces misleading conclusions and adaptation goes in the wrong direction.

A Scrum pillar describing the recurring cycle of examining artifacts and progress and then adjusting course. Scrum events such as the Daily Scrum, Sprint Review, and Sprint Retrospective exist to create regular, focused opportunities for this.

A small, self-managing group made up of one Scrum Master, one Product Owner, and Developers. The whole team shares accountability for delivering a valuable, useful Increment each Sprint and typically numbers ten or fewer people.

The single accountable person for maximizing product value. This person owns and orders the Product Backlog, communicates the product goal, and makes trade-off decisions so the team works on the most valuable items.

The role accountable for the Scrum Team's effectiveness. This person coaches the team in Scrum practices, removes impediments, and helps the organization understand how to work with the team, serving rather than directing.

The Scrum Team members who create the Increment each Sprint. They self-manage their work, turn backlog items into a usable product, and hold one another accountable for quality and for meeting the Definition of Done.

A fixed-length iteration of one month or less in which a usable, potentially releasable Increment is created. A new Sprint starts immediately after the previous one ends, and its scope is protected from disruptive change.

A maximum duration set for a Scrum event or Sprint. Timeboxes create a regular rhythm and force prioritization; if the purpose of an event is achieved earlier, the event can end sooner than the limit.

A short statement of the single objective for the Sprint that gives the team focus and flexibility. It is agreed collaboratively during Sprint Planning and guides what work the Developers commit to.

The event that opens a Sprint, where the team agrees on the Sprint Goal, selects Product Backlog items, and plans how the work will be done. It is timeboxed to a maximum of eight hours for a one-month Sprint.

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 for the team, not a status report to management.

An event at the end of the Sprint where the team and stakeholders inspect the Increment and discuss what to do next. It is a collaborative working session that may adjust the Product Backlog, not a formal sign-off gate.

The final event of a Sprint, where the team inspects how it worked and identifies improvements to apply in the next Sprint. Its output is actionable change, ideally at least one concrete improvement.

The concrete, usable result produced during a Sprint that meets the Definition of Done. Each Increment adds to previous ones and must be in a state that could be delivered to users.

A shared, explicit checklist describing the quality attributes an Increment must have to be considered complete. It makes transparency real and prevents work from being counted as finished prematurely.

An emergent, ordered list of everything that might be needed to improve the product. The Product Owner owns it, and it is the single source of work for the team, refined continuously rather than written once.

A long-term objective describing the future state of the product that the team works toward. It provides direction for the Product Backlog and is replaced only when it is met or abandoned.

A concise description of the desired future state of the product and the value it delivers to its users. It aligns stakeholders and gives the team a reason to care about the work beyond individual backlog items.

The ongoing activity of reviewing backlog items to add detail, estimates, and order so they are ready for future Sprints. It is a continuous conversation, not a one-time grooming meeting.

A short description of a need written from the user's perspective, often in the form role, capability, and benefit. It is a placeholder for a conversation, not a full specification.

The conditions a backlog item must satisfy to be accepted by the Product Owner. They clarify intent, support testing, and reduce ambiguity about what done means for a specific item.

An optional team agreement describing what a backlog item should look like before it enters a Sprint. It is a helpful conversation aid but is not prescribed by Scrum and should not become a rigid gate.

The act of ordering backlog items by value, risk, cost, or dependency so the team works on the most important things first. In Scrum, order is the primary lever the Product Owner uses to steer outcomes.

A prioritization technique that classifies items as Must have, Should have, Could have, or Will not have this time. It helps stakeholders discuss trade-offs explicitly, especially when scope must be protected within a fixed timeline.

The worth or benefit a product delivers to users and the organization, which the Product Owner is accountable for maximizing. Value is not the same as output volume and should be measured, not assumed.

Anyone with an interest in the product, such as customers, users, managers, or support staff. The Product Owner engages them to understand needs and to keep expectations aligned with what the team is building.

The ongoing practice of identifying stakeholders, understanding their interests, and keeping them appropriately informed and involved. It balances competing demands while protecting the team from disruptive, unfiltered requests.

A lightweight, often outcome-based view of how the product is expected to evolve over time. It communicates direction and intent without promising fixed dates or features that would undermine agility.

The accumulated cost of shortcuts in design or code that make future change harder. The Product Owner should understand it and prioritize repayment work, because it affects the team's long-term ability to deliver value.

Anything blocking the team from making progress, such as missing access, unclear requirements, or unresolved dependencies. The Scrum Master typically helps remove impediments, though the team also addresses them.

A team that decides internally who does what, when, and how, rather than being directed task by task. This autonomy is central to Scrum and requires clear goals and boundaries to work well.

The specific duties of the Product Owner role, including ordering the backlog, communicating the Product Goal, and ensuring the backlog is visible and understood. Accountability cannot be delegated to a committee.

A 2001 statement of four values and twelve principles that shaped modern Agile practice, favoring individuals, working software, collaboration, and responsiveness over rigid process. Scrum is one framework that embodies these values.

A team-specific measure of how much backlog work is completed per Sprint, used for forecasting rather than comparison across teams. It is a planning aid, not a productivity target to be maximized.

A unitless estimate of relative size and complexity for a backlog item. Because it is relative, story points support team discussion and forecasting but should not be converted to hours or compared between teams.