EXIN Agile Scrum Product Owner Bridge key terms

A short statement of four values and twelve principles that guides Agile work, prioritising individuals, working software, customer collaboration and response to change over rigid plans and documents.

A way of managing work through frequent inspection and adaptation of what is actually happening, rather than following a detailed predetermined plan. It relies on transparency, inspection and adaptation.

The recurring rhythm in which the team examines its product, process and progress at fixed points and then changes what it does next based on what it learned.

A leadership stance in which the person in authority focuses on removing obstacles, growing the team and enabling others to succeed, rather than directing and controlling their daily work.

A group that decides internally how to organise and carry out its own work, rather than waiting for a manager to assign tasks and methods.

A group holding all the skills needed to deliver a working product increment without depending on outside specialists for each step of the work.

Fixing a maximum duration for an activity so that scope adjusts to fit the time, rather than letting the activity expand until everything is finished.

A lightweight structure of roles, events and artefacts in which a small team delivers valuable increments in short fixed cycles, using transparency and frequent adaptation.

The single person accountable for maximising the value of the product, owning the Product Backlog and deciding what is built, in what order, and what counts as acceptable.

The ongoing pursuit of the greatest possible benefit from the product relative to its cost and risk, expressed in the ordering and content decisions the Product Owner makes.

An informal image for the rule that one named person, not a committee, answers for product decisions, so accountability is clear and decisions can be made quickly.

Identifying the people affected by or interested in the product and keeping them informed, involved and aligned so that their needs inform decisions without derailing the team.

A single longer-term objective describing the future state of the product that the team works toward, giving the backlog a direction and a reason for its ordering.

A concise description of the product's intended future and the value it should create for its users, used to keep decisions coherent over many sprints.

The role accountable for the team's effectiveness, coaching the organisation in Scrum, facilitating events and helping remove impediments, without owning product content decisions.

An ordered, evolving list of everything that might be built into the product, with the most valuable and best-understood items at the top and detail increasing as items rise.

A single entry on the backlog, such as a feature, fix or improvement, described at whatever level of detail is appropriate for its position in the ordering.

The continuing activity of adding, reordering, splitting and clarifying backlog items so that upcoming work is understood well enough to be selected in a future sprint.

Deciding the order in which backlog items should be delivered, weighing value, risk, dependencies, cost and timing, so that the most useful things come first.

A grouping technique that sorts requirements into Must have, Should have, Could have and Will not have this time, useful for agreeing scope under a fixed deadline.

A short description of a need written from a user's perspective, usually stating who wants it, what they want and why, and serving as a placeholder for a later conversation.

The conditions a backlog item must satisfy to be accepted, written so that the team and the Product Owner share the same understanding of what done means for that item.

A shared, explicit checklist of what must be true for any increment to be considered complete, applied to every item rather than negotiated per item.

An optional team agreement listing what must be true before a backlog item can be taken into a sprint, such as clear value, criteria and small enough size.

A memory aid for well-formed backlog items: Independent, Negotiable, Valuable, Estimable, Small and Testable, used when writing and splitting stories.

Breaking a large backlog item into smaller ones that each still deliver some value, so they can be completed within a single sprint and ordered independently.

A fixed-length cycle, commonly one to four weeks, at the end of which a usable increment is produced; scope may be clarified but the length does not change.

A single objective for one sprint that gives the team focus and flexibility, describing the value to be achieved rather than a list of tasks.

The event at the start of a sprint where the team agrees why the sprint is valuable, what can be delivered and how the work will be approached.

The subset of backlog items selected for the current sprint, together with the team's plan for delivering them and achieving the sprint goal.

A short daily event, timeboxed to fifteen minutes, in which the team inspects progress toward the sprint goal and adjusts its plan for the next day.

The event at the end of a sprint where the increment is inspected with stakeholders, feedback is gathered and the backlog may be adjusted for what comes next.

A closing event in which the team examines how it worked together and identifies concrete improvements to apply in the next sprint.

The sum of completed backlog items produced during a sprint, which must be usable and meet the definition of done to count as finished.

A measure of how much backlog work a team completes per sprint, useful for forecasting over several sprints but not as a target or a performance rating.

A relative unit used to size backlog items by effort, complexity and uncertainty together, so estimates stay comparable without pretending to be exact hours.

A group estimation technique in which each team member privately chooses a card, then differences are discussed until a shared estimate emerges.

A project whose behaviour cannot be reliably predicted from past data because many interacting variables and unknowns are present, so learning by doing is required.

A sense-making model that sorts situations into clear, complicated, complex and chaotic domains, each calling for a different decision approach from best practice to experimentation.

The idea that useful patterns and answers appear through the work itself and cannot be fully planned in advance, so plans are expected to change as understanding grows.

Looking ahead across several sprints to forecast when a set of valuable functionality might be available, using velocity and backlog order as inputs rather than promises.

The smallest version of a product that lets real users try it and generates learning about what to build next, rather than a stripped-down final product.

The accumulating cost of shortcuts in design or code that make future change slower, which the Product Owner must weigh against feature work when ordering the backlog.

The benefit gained relative to the cost invested, a common lens for comparing backlog items and deciding which delivery order creates the most value soonest.