EXIN Agile Scrum Product Owner flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Three pillars of Scrum

Transparency, inspection, and adaptation. Together they enable empirical process control: work and progress are visible, checked frequently, and adjusted when results deviate from expectations.

Agile Manifesto values

Individuals and interactions, working software, customer collaboration, and responding to change are valued over their counterparts, while the items on the right retain value.

Scrum values

Commitment, courage, focus, openness, and respect. These five values guide the behavior of everyone in the Scrum Team and support the empirical pillars.

Empiricism

The principle that knowledge comes from experience and decisions are made on observation. Scrum applies it through transparency, frequent inspection, and adaptation rather than detailed upfront plans.

Iterative and incremental

Iterative means repeating cycles to refine; incremental means adding finished pieces. Scrum does both, producing a usable Increment each Sprint and refining it over time.

Timebox

A fixed maximum duration for an event, such as 15 minutes for the Daily Scrum or one month for the Sprint. The timebox is not extended; scope adjusts instead.

Complexity and Scrum fit

Scrum is designed for complex work where requirements and technology are not fully understood, so cause and effect emerge only in retrospect and plans must adapt.

Product Owner accountability

One person accountable for maximizing the value of the product resulting from the Scrum Team's work. The role may delegate tasks but never the accountability itself.

Product Backlog ownership

The Product Owner is the sole authority for ordering and managing the Product Backlog, ensuring it is visible, transparent, and shows what the team will work on next.

PO and Definition of Done

The Product Owner confirms that Increments meet the agreed Definition of Done before they are considered releasable; quality criteria are agreed with the Developers.

PO availability

The Product Owner must be reachable to clarify requirements and answer questions during the Sprint; unavailability commonly causes rework, wrong scope, and failed Sprint Goals.

PO versus Scrum Master

The Product Owner decides what and why, ordering the backlog for value. The Scrum Master serves the process, removing impediments and coaching the team on Scrum.

PO and stakeholders

The Product Owner gathers stakeholder input, communicates progress, and negotiates scope, acting as the single point of contact between the Scrum Team and its stakeholders.

PO and technical decisions

The Product Owner does not dictate how items are built. Technical design, architecture, and implementation approach belong to the Developers on the Scrum Team.

Product Goal

A long-term objective for the Scrum Team recorded in the Product Backlog. It provides a target for planning and is replaced once achieved or abandoned.

Backlog refinement

The ongoing activity of breaking down and clarifying backlog items into smaller, more precise entries. It typically consumes no more than ten percent of team capacity.

User story format

As a role, I want a goal so that a benefit. It expresses a need from the user's perspective and is completed by acceptance criteria defining when it is done.

INVEST criteria

A checklist for good backlog items: Independent, Negotiable, Valuable, Estimable, Small, and Testable. Items failing these criteria are refined further before planning.

Definition of Done

A formal description of the quality state required for an Increment. It applies to every backlog item and is agreed by the whole Scrum Team.

Definition of Ready

An optional team agreement describing when a backlog item is sufficiently understood to enter Sprint Planning. It is not defined in the Scrum Guide.

Story points

A relative unit for estimating effort, complexity, and uncertainty using comparison rather than hours. Points are team-specific and support velocity-based forecasting.

Velocity

The amount of backlog work a team completes per Sprint, measured in its chosen unit. It supports forecasting but is not a performance target or productivity measure.

Stacey matrix

A model plotting work by agreement on requirements versus technology. Low agreement on both places work in the complex or chaotic zone where empirical approaches suit.

Cynefin framework

A sense-making model with clear, complicated, complex, and chaotic domains. Complex work uses probe-sense-respond because cause and effect appear only in hindsight.

Cone of uncertainty

The observation that estimates are widest early in a project and narrow as work progresses and knowledge grows, so early forecasts should be given as ranges.

Emergent backlog

A backlog that evolves as learning occurs. Ordering and content change with new insight, while the Sprint Goal provides short-term stability within the Sprint.

Vertical slicing

Splitting work so each piece delivers a thin end-to-end function across all layers, rather than a single technical layer, enabling early feedback and value.

Spike

A timeboxed investigation on the backlog whose purpose is to gain knowledge or reduce uncertainty, such as evaluating a technology before committing to a solution.

Kano model

A classification of features as must-be, performance, attractive, indifferent, or reverse. Must-be features prevent dissatisfaction; attractive features create disproportionate delight.

MoSCoW prioritization

Scope labeled Must have, Should have, Could have, and Won't have this time. All Must items must be delivered for the iteration to be considered successful.

Minimum Viable Product

The smallest product version that allows validated learning from real users. It is a learning instrument to test assumptions, not simply a low-quality release.

Cost of delay

The economic loss caused by not delivering an item sooner. Dividing cost of delay by duration gives a ranking heuristic for ordering backlog items.