EXIN Agile Scrum Product Owner key terms

A way of managing work where decisions rest on observation of actual results rather than on a detailed up-front plan. Transparency, inspection and adaptation are its three pillars, and it suits work whose outcome cannot be predicted in advance.

The repeating rhythm in which the team and stakeholders look at what was actually produced and then change plans, process or product accordingly. Inspection without a resulting change is wasted effort.

A property of problems where the relationship between cause and effect can only be seen in hindsight, so predicting the right answer up front is impossible. Scrum is designed for this kind of work rather than for simple or merely complicated tasks.

A sense-making model that sorts situations into clear, complicated, complex and chaotic domains, each calling for a different response. Complex problems need safe-to-fail probes and emergent practice rather than expert analysis of the whole.

A model plotting agreement about what is wanted against certainty about how to achieve it. Where both are low the situation is complex or chaotic, and iterative, empirical approaches work better than linear planning.

The practice of letting structure, architecture and requirements grow from working software and feedback instead of fixing them all at the start. It accepts that understanding improves as the product is built and used.

A short 2001 statement of four values and twelve principles for software development, favouring people, working software, collaboration and responsiveness over documentation, contracts and rigid plans. It sets the mindset behind Scrum rather than prescribing practices.

The twelve supporting statements of the Agile Manifesto, covering early and continuous delivery, welcoming changing requirements, frequent collaboration, self-organising teams and regular reflection. They guide how a Product Owner behaves, not only what artefacts exist.

A lightweight framework in which a small cross-functional team turns a prioritised list of needs into a usable product increment in short fixed cycles, inspecting and adapting as it goes. It defines roles, events and artefacts but not detailed engineering practice.

A fixed-length cycle, usually one to four weeks, during which the team builds a usable increment. Its length is kept constant to create a predictable rhythm, and scope may be renegotiated with the Product Owner while the goal stays protected.

Giving an activity a fixed maximum duration that is not extended, so that the effort spent stays proportionate and decisions actually get made. It applies to every Scrum event, including daily scrum and sprint planning.

The single person accountable for maximising the value the team delivers, chiefly by ordering the product backlog and making its content clear. The role carries decision authority over what is built and in which order, and cannot be spread across a committee.

The Product Owner's core accountability: choosing work that returns the most benefit relative to cost and risk, and ordering the backlog so the most valuable items come first. Value can be revenue, risk reduction, learning or user satisfaction.

Identifying everyone with an interest in the product, understanding their needs and expectations, and keeping them engaged and informed without letting any one of them override the ordering of the backlog. It includes saying no and explaining why.

A short, compelling description of the future the product is meant to create and for whom. It gives the team a shared direction against which backlog items can be judged, and it stays stable while individual features change.

A longer-lived objective the Scrum Team plans towards, describing a future state of the product that gives the backlog a target. Each sprint should move the product measurably closer to it, and it is replaced only when achieved or abandoned.

An ordered, evolving list of everything that might be needed to improve the product, and the single source of work for the team. Its top items are small and ready to build; lower items stay coarse until they rise.

The set of activities the Product Owner uses to keep the backlog healthy: expressing items clearly, ordering them by value, refining them with the team, and making priorities visible. It is continuous work, not a one-off planning task.

Arranging backlog items so the most valuable, riskiest or most enabling ones sit at the top. Ordering, not numerical scoring, is what tells the team what to work on next; items may be reordered whenever new information arrives.

Deciding what to do first and what to leave out, using criteria such as value, cost, risk, dependencies and learning. Techniques include MoSCoW, weighted shortest job first and cost of delay, but the Product Owner remains accountable for the outcome.

A grouping technique that labels requirements Must have, Should have, Could have and Won't have for a given time frame. It forces explicit agreement about the minimum usable set and what can be dropped if time runs short.

The economic loss caused by not having a feature or outcome available for a period of time. Comparing it with the effort needed helps order work by value density rather than by who shouts loudest.

An ordering rule that divides the value of an item by its duration or size, so short high-value items go first. It maximises value delivered over a fixed period compared with sorting by value alone.

The ongoing activity of reviewing backlog items with the team to add detail, split large ones, re-estimate and reorder them. It keeps enough top items ready for the next sprint without over-specifying distant work.

A short description of a need written from a user's perspective, usually stating who wants it, what they want and why. It is a placeholder for a conversation, not a complete specification, and is completed by acceptance criteria.

The conditions a backlog item must satisfy to be accepted by the Product Owner, written so they can be checked objectively. They clarify intent and become the basis for testing and for the definition of done at item level.

A checklist for a good backlog item: independent, negotiable, valuable, estimable, small and testable. Items failing it usually need splitting or more conversation before a sprint can rely on them.

Breaking a large backlog item into smaller ones that each still deliver something demonstrable or testable. Common patterns split by workflow step, business rule, data type or happy path versus edge cases.

A team-agreed checklist describing when a backlog item is understood, small and testable enough to be taken into a sprint. It is a helpful convention rather than a Scrum rule, and should not become a bureaucratic gate.

A shared, explicit list of what must be true for an increment to count as complete, such as tested, reviewed and documented. The team applies it to every item, and the Product Owner uses it to decide whether work is really finished.

The sum of all completed backlog items at the end of a sprint, in a usable condition that meets the definition of done. It must be potentially releasable even if the organisation chooses not to release it.

The event that opens a sprint, where the team agrees a sprint goal and selects backlog items it can finish. The Product Owner brings an ordered backlog and discusses value; the team owns the forecast of how much it can do.

A single sentence describing the purpose of the coming sprint and the value it should deliver. It gives the team focus and a basis for negotiating scope during the sprint when new information appears.

A short daily event, timeboxed to fifteen minutes, where the developers inspect progress towards the sprint goal and adapt their plan for the next day. The Product Owner may attend but does not run it or direct the work.

The event at the end of a sprint where the team shows the increment to stakeholders and collects feedback. It is a working session to inspect the product and adapt the backlog, not a formal sign-off presentation.

A closing event in which the team examines how it worked together and picks improvements for the next sprint. The Product Owner takes part as a team member and can raise process issues affecting value delivery.

The small group made of one Product Owner, one Scrum Master and the developers, collectively accountable for delivering value each sprint. It is cross-functional and self-managing, with no sub-teams or hierarchy inside it.

The role accountable for the team's effectiveness in using Scrum, coaching the team and the organisation, removing impediments and shielding the team from disruption. This person serves the Product Owner by helping with backlog techniques and stakeholder collaboration.

A style of leading by serving the team's needs, removing obstacles and coaching rather than commanding. Both the Scrum Master and, in relation to stakeholders, the Product Owner practise it.

A team that decides for itself how to carry out its work, including who does what and how tasks are distributed, rather than being directed task by task. The Product Owner sets what and why; the team decides how.

The accumulated cost of shortcuts in design or code that make future change slower and riskier. The Product Owner should keep it visible in the backlog and spend capacity on it, because value delivery eventually depends on it.

Improving the internal structure of software without changing its observable behaviour. It is a routine part of building incrementally and should be covered by the definition of done rather than treated as a separate project.

Coordinating several Scrum teams that work on one product or related products, for example through frameworks such as LeSS, Nexus or SAFe. It adds planning and integration overhead, so it should be adopted only when one team is genuinely insufficient.

A situation where one backlog item or team cannot progress until another is finished. Dependencies slow delivery and should be surfaced early, reduced by splitting work or reordering the backlog, and tracked visibly.

Anything blocking the team from making progress, such as a missing decision, unavailable environment or unresolved dependency. The Scrum Master is accountable for having it removed, and the Product Owner often resolves the business-side ones.

The smallest version of a product that lets a real user complete a real task and generates learning about what to build next. It is about validated learning, not about shipping something half-finished.

Deciding which increments to make available to users and when, balancing value, risk and readiness. In Scrum it is a forecast rather than a commitment, and it is revised as the backlog and feedback change.

A lightweight, outcome-oriented view of where the product is heading over coming periods, showing goals rather than fixed feature dates. It communicates direction to stakeholders while leaving room to adapt to what is learned.

The amount of backlog work a team completes per sprint, measured in whatever size unit it estimates with. It is a planning aid for forecasting within one team, never a target or a basis for comparing teams.

A relative unit used to size backlog items by effort, complexity and uncertainty together. Because the scale is team-specific, points support internal forecasting and should not be converted into hours or compared across teams.

A collaborative estimation technique in which each team member reveals a card simultaneously and outliers explain their reasoning before a value is agreed. It reduces anchoring and spreads understanding of the item across the team.