Overview
This competency covers the five framework focus areas Scrum.org lists for PSPO I: Empiricism, Scrum Team, Events, Artifacts and Done. The content is the Scrum Guide, but the PSPO I asks about it from the Product Owner's position: who decides the order of the Product Backlog, what the Product Owner brings to Sprint Planning, when a Sprint may be cancelled, and why an item that misses the Definition of Done cannot be shown as finished.
Candidates need precise rules, not workplace habits. Timeboxes, the single Product Owner, one Product Backlog per product, the commitment attached to each artifact and the boundary between the Product Owner's say over what and the Developers' say over how are all fixed by the Guide. That framework knowledge is what makes the product-management focus areas answerable, because a Product Goal, release decision or stakeholder conversation only makes sense once the mechanics are solid.
How it's tested
Questions here are short scenarios or direct rule checks, often in multiple-answer or true/false form. Most ask what the Product Owner should do, who is accountable for something, or whether a practice is allowed by the Scrum Guide. The reasoning is to locate the accountability first, then check the rule, then reject options built on common but non-Scrum habits.
-
Who owns this decision
A decision is described (ordering, sizing, task assignment, Sprint cancellation) and you pick the accountability the Scrum Guide gives it to. The Product Owner owns what and why; the Developers own how and how much.
-
Is this allowed in Scrum
A practice such as a backlog committee, a stabilization Sprint or skipping a Retrospective is proposed. You judge it against the Guide's rules, not against whether it sounds practical.
-
Artifact and commitment pairing
A goal or quality standard is named and you match it to its artifact: Product Goal with Product Backlog, Sprint Goal with Sprint Backlog, Definition of Done with the Increment.
Halfway through a Sprint, the Developers tell the Product Owner that the selected work is larger than expected. A tempting option is that the Product Owner cuts testing so everything ships. Find the owner: the Developers manage the Sprint Backlog and quality is fixed by Done. Then apply the rule: scope is renegotiated with the Product Owner as more is learned, without endangering the Sprint Goal. The answer is to clarify and renegotiate scope, not to lower quality.
Focus areas 5
Official focus areas from the Scrum.org outline, in outline order.
1.1 EmpiricismTransparency, inspection and adaptation as the basis for product decisions.
- What it means
- Empiricism means knowledge comes from experience and decisions rest on what has actually been observed. Scrum makes it work through three pillars: transparency of the process and work, inspection of artifacts and progress, and adaptation as soon as a deviation is found.
- What to understand
- For a Product Owner, empiricism means treating every backlog item and plan as a hypothesis that each Increment tests. The pillars depend on each other: low transparency makes inspection misleading, and inspection without the authority or willingness to adapt is wasted. The Scrum Values (commitment, focus, openness, respect, courage) are what make that transparency possible in practice.
- How it shows up
- A scenario describes a long upfront specification, a hidden quality problem or a plan nobody revisits, and asks which pillar is missing or what the Product Owner should change.
- Common confusion
- Candidates treat empiricism as a reporting practice. Producing more status documents does not add transparency if the Increment and the Product Backlog do not show the real state of the work.
1.2 Scrum TeamThe Product Owner, Scrum Master and Developers as one team with distinct accountabilities.
- What it means
- The Scrum Team is one cohesive, cross-functional, self-managing unit, typically 10 or fewer people, with one Scrum Master, one Product Owner and the Developers. The Product Owner is accountable for maximizing the value of the product resulting from the Scrum Team's work.
- What to understand
- The Product Owner is one person, not a committee, and remains accountable even when delegating backlog work to others. The Product Owner develops and communicates the Product Goal, creates and communicates Product Backlog items, orders them and keeps the backlog transparent. The organization must respect the Product Owner's decisions, and anyone who wants a change persuades the Product Owner.
- How it shows up
- Questions ask who orders the Product Backlog, who sizes items, who chooses how work is done, or what to do when two executives each want to act as Product Owner.
- Common confusion
- Candidates confuse delegation with transfer: a Product Owner may let Developers write backlog items, but accountability for the backlog's content and order stays with the Product Owner.
1.3 EventsThe Sprint and the four events inside it, with purposes and timeboxes.
- What it means
- The Sprint is a fixed-length container of one month or less in which all other events happen: Sprint Planning (up to 8 hours for a one-month Sprint), the Daily Scrum (15 minutes, for the Developers), the Sprint Review (up to 4 hours) and the Sprint Retrospective (up to 3 hours). Shorter Sprints usually get shorter events.
- What to understand
- The Product Owner arrives at Sprint Planning ready to explain how the product could increase its value and usefulness that Sprint, the whole Scrum Team then crafts the Sprint Goal, and the Developers decide how much to select and how to do it. Only the Product Owner may cancel a Sprint, and only when the Sprint Goal has become obsolete. The Sprint Review is a working session with stakeholders that adapts the Product Backlog, not a sign-off gate.
- How it shows up
- Typical prompts: the Product Owner wants to join the Daily Scrum to assign work, a stakeholder wants to approve the Increment at the Sprint Review, or market news makes the Sprint Goal pointless.
- Common confusion
- Many candidates think the Sprint Review is where releases are approved. The Guide says it should never be treated as a gate to releasing value; Increments can be delivered before the Sprint ends.
1.4 ArtifactsProduct Backlog, Sprint Backlog and Increment, and the commitment each carries.
- What it means
- Scrum has three artifacts, each paired with a commitment that gives it focus: the Product Backlog with the Product Goal, the Sprint Backlog with the Sprint Goal, and the Increment with the Definition of Done. The Product Backlog is the single, ordered, emergent source of work for the product.
- What to understand
- One product has one Product Backlog and one Product Owner, even when several Scrum Teams work on it. The Product Goal is a future state of the product held in the Product Backlog, and the team works toward one at a time. The Sprint Backlog belongs to the Developers: it holds the Sprint Goal (why), the selected items (what) and their plan (how), and they update it throughout the Sprint.
- How it shows up
- Questions present a team with separate backlogs per team, a Product Owner editing the Sprint Backlog, or ask which commitment belongs to which artifact.
- Common confusion
- Candidates pair the Product Goal with the Sprint Backlog or think the Product Owner owns the Sprint Backlog. The Product Owner owns the Product Backlog; the Developers own the Sprint Backlog.
1.5 DoneThe Definition of Done and what counts as an Increment.
- What it means
- The Definition of Done is a formal description of the state the Increment must reach to meet the product's quality measures. An item becomes part of an Increment the moment it meets the Definition of Done, and several Increments can be created in one Sprint.
- What to understand
- If the organization has a Definition of Done, every Scrum Team uses it as a minimum; otherwise the Scrum Team creates one. Teams sharing a product share one Definition of Done. Anything short of it cannot be released or presented at the Sprint Review and goes back to the Product Backlog for the Product Owner to reconsider.
- How it shows up
- A Product Owner is pressured to release a feature that passed functional testing but not the security checks in Done, or to show undone work at the Sprint Review to please stakeholders.
- Common confusion
- Candidates mix up Done with acceptance criteria. Acceptance criteria describe one item's behavior; the Definition of Done sets the quality bar for every Increment.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Product Owner accountability
The Product Owner is accountable for maximizing the value of the product that results from the Scrum Team's work, not for maximizing output or keeping stakeholders happy.
- Remember
- One person, not a committee, and accountable even when backlog tasks are delegated to Developers or others.
- Tested as
- Any question about who decides the order or content of the Product Backlog points here.
- Trap
- Choosing an answer where a steering group votes on priorities, which removes the single point of accountability.
-
Product Goal
The Product Goal is a future state of the product that the Product Backlog emerges toward; it is the commitment attached to the Product Backlog.
- Remember
- The Scrum Team pursues one Product Goal at a time and fulfills or abandons it before taking the next.
- Tested as
- Questions ask which artifact the Product Goal belongs to or who develops and communicates it, which is the Product Owner.
- Trap
- Pairing it with the Sprint Backlog, or treating it as a fixed scope document rather than a target that guides ordering.
-
Sprint Goal
The Sprint Goal is the one objective that gives the Sprint coherence, crafted by the whole Scrum Team during Sprint Planning and committed to by the Developers.
- Remember
- Scope may be clarified and renegotiated with the Product Owner during the Sprint, but changes must not endanger the Sprint Goal.
- Tested as
- Mid-Sprint change requests are judged by whether they protect the Sprint Goal.
- Trap
- Thinking the Product Owner writes the Sprint Goal alone and hands it to the Developers.
-
Sprint cancellation
A Sprint can be cancelled only if its Sprint Goal becomes obsolete, and only the Product Owner has the authority to cancel it.
- Remember
- The trigger is an obsolete goal, not slow progress or a sick team member.
- Tested as
- Scenarios about market shifts, acquisitions or withdrawn requirements test both who and why.
- Trap
- Selecting the Scrum Master or a manager as the person who cancels, or cancelling because the Developers are behind.
-
Event timeboxes
For a one-month Sprint, Sprint Planning is at most 8 hours, the Sprint Review at most 4 hours and the Retrospective at most 3 hours; the Daily Scrum is 15 minutes regardless of Sprint length.
- Remember
- These are maximums; shorter Sprints usually use shorter events.
- Tested as
- Direct recall questions and scenarios where an event overruns.
- Trap
- Scaling the Daily Scrum to Sprint length or treating the maximums as required durations.
-
Sprint Planning topics
Sprint Planning answers three topics: why this Sprint is valuable, what can be Done this Sprint, and how the chosen work will get done.
- Remember
- The Product Owner proposes how the product could increase its value; the Developers select the items and plan the how.
- Tested as
- Questions ask what the Product Owner must bring or who decides how many items enter the Sprint.
- Trap
- Assuming the Product Owner decides how much work the Developers take on.
-
Sprint Review purpose
The Sprint Review inspects the outcome of the Sprint with key stakeholders and decides future adaptations, often by changing the Product Backlog.
- Remember
- It is a working session, not a demo or approval gate, and value can be released before it.
- Tested as
- Stakeholder and release scenarios check whether you treat the Review as a gate.
- Trap
- Believing an Increment may only be released after the Sprint Review.
-
Definition of Done
The Definition of Done is the shared quality standard that turns finished work into an Increment and creates transparency about what complete means.
- Remember
- An organizational Definition of Done is a minimum for every team; teams on one product share one Definition of Done.
- Tested as
- Release-pressure scenarios test whether you let undone work out.
- Trap
- Lowering Done for one deadline instead of returning the item to the Product Backlog.
-
One product, one backlog
Each product has exactly one Product Backlog and one Product Owner, no matter how many Scrum Teams work on it.
- Remember
- Multiple teams on one product pull from the same Product Backlog and share the same Product Goal.
- Tested as
- Scaling questions where each team wants its own backlog or Product Owner.
- Trap
- Choosing team-level Product Owners to reduce the load, which splits accountability for value.
-
Refinement
Product Backlog refinement is the ongoing activity of breaking down items and adding detail such as description, order and size.
- Remember
- It is not an event; the Developers who will do the work are responsible for sizing.
- Tested as
- Questions ask when refinement happens or who estimates.
- Trap
- Treating refinement as a required meeting or having the Product Owner estimate items for the Developers.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Product Backlog vs. Sprint Backlog vs. Increment
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Product Backlog | The single ordered, evolving source of all product work | Owned by the Product Owner; its commitment is the Product Goal | Thinking each team on a shared product keeps its own Product Backlog |
| Sprint Backlog | Sprint Goal, selected Product Backlog items and the Developers' plan | Owned and updated by the Developers; its commitment is the Sprint Goal | Assuming the Product Owner may add or reorder tasks in it directly |
| Increment | A usable step toward the Product Goal that meets the Definition of Done | Its commitment is the Definition of Done; several can be made in one Sprint | Counting work that is almost done as part of the Increment |
Product Owner vs. Developers vs. Scrum Master
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Product Owner | Maximizes product value and manages the Product Backlog | Decides order and content of the Product Backlog and may cancel a Sprint | Assigning tasks or choosing the technical approach |
| Developers | Create a usable Increment each Sprint and plan their own work | Select how much work to take, size items and decide how to build them | Being told by the Product Owner how many items they must complete |
| Scrum Master | Answers for how effective the Scrum Team is and for establishing Scrum | Serves the Product Owner with backlog techniques and empirical product planning | Being treated as the person who resolves priority disputes on the Product Owner's behalf |
Definition of Done vs. acceptance criteria
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Definition of Done | Quality standard every Increment must meet | Applies to all work on the product and is shared by all teams on it | Relaxing it for one urgent item |
| Acceptance criteria | Conditions describing one item's expected behavior | Specific to a single Product Backlog item; not defined in the Scrum Guide | Believing an item that meets its criteria is releasable even if it fails Done |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Product Owner assigns work at the Daily Scrum
- What candidates pick
- The Product Owner attends the Daily Scrum to hand out tasks and check progress on priority items.
- Why it looks right
- The Product Owner knows the priorities, so steering the day's work sounds efficient.
- Why it's wrong
- The Developers own the Daily Scrum and use it to inspect progress toward the Sprint Goal and adapt their plan; how the work is done is theirs to decide.
Clue to watch for The option has the Product Owner directing individuals or turning the event into a status report.
-
Committee ordering
- What candidates pick
- A steering group of business leaders votes on Product Backlog order each Sprint.
- Why it looks right
- It looks inclusive and gives executives visible control.
- Why it's wrong
- The Product Owner is one person whose ordering decisions the organization must respect; stakeholders influence by persuading the Product Owner.
Clue to watch for Words like vote, board or committee attached to Product Backlog order.
-
Cancelling for slow progress
- What candidates pick
- The Product Owner cancels the Sprint because the Developers will not finish every selected item.
- Why it looks right
- Restarting with a fresh plan feels like a clean fix.
- Why it's wrong
- Cancellation is only for an obsolete Sprint Goal; incomplete scope is renegotiated with the Product Owner while the Sprint Goal still holds.
Clue to watch for Check whether the Sprint Goal itself still makes sense; if it does, cancellation is wrong.
-
Releasing almost-done work
- What candidates pick
- The Product Owner releases a feature that passed functional tests but skipped performance tests required by Done.
- Why it looks right
- The customer is waiting and the feature appears to work.
- Why it's wrong
- An item that misses the Definition of Done never joins an Increment and cannot be released; it returns to the Product Backlog.
Clue to watch for Any mention that a Definition of Done step was skipped.
-
Product Owner sizes the items
- What candidates pick
- The Product Owner estimates Product Backlog items so planning goes faster.
- Why it looks right
- The Product Owner understands the requirements best.
- Why it's wrong
- The Developers who will do the work are responsible for sizing; the Product Owner influences by explaining the items and the trade-offs.
Clue to watch for The question asks who estimates, sizes or forecasts capacity.
-
Waiting for the Sprint Review to release
- What candidates pick
- The Product Owner holds a Done Increment until the Sprint Review so stakeholders can approve it.
- Why it looks right
- Many organizations use the Review as a demo-and-sign-off meeting.
- Why it's wrong
- The Scrum Guide says the Sprint Review should never be a gate to releasing value; a Done Increment may be delivered earlier.
Clue to watch for A Done Increment exists before the Sprint ends and a customer need is waiting.
Answer framework
Use this sequence for any PSPO I question about Scrum rules or accountabilities.
- Identify whether the decision is about what and why, which belongs to the Product Owner, or about how and how much, which belongs to the Developers.
- Name the event, artifact or commitment the scenario sits in and recall its purpose and timebox.
- Check for a fixed Scrum Guide rule: one Product Owner, one Product Backlog, Definition of Done as the quality floor, cancellation only for an obsolete Sprint Goal.
- Reject options that copy common workplace habits, such as approval gates, committees, status meetings or lowered quality for a deadline.
- Prefer the option that keeps transparency and lets the Scrum Team inspect and adapt using real evidence.
Practice question
Want more like this? The PSPO I practice test has questions for every domain.
Checklist
0 of 12
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with a slow, complete read of the Scrum Guide, marking every sentence that names the Product Owner. Those sentences define most of this competency: the Product Owner's accountability, the backlog activities, the role in Sprint Planning and the Sprint Review, and the cancellation rule. Then build a one-page sheet of events with purpose, timebox and attendees, and a second of artifacts with owner and commitment.
The highest-priority concepts are the boundary between what and how, the single Product Owner, the Definition of Done as an unchangeable quality floor, and Sprint cancellation. Commonly underestimated areas are the Developers' ownership of the Sprint Backlog and sizing, the rule that several teams on one product share one backlog and one Definition of Done, and the statement that the Sprint Review is not a release gate. Candidates who use Scrum at work should flag every place their team's habits differ from the Guide.
Afterwards, take Scrum.org's free Product Owner Open assessment repeatedly until you score well above the 85% bar, then switch to timed practice. With 80 questions in 60 minutes you have under a minute per item, so rule recall must be quick.
FAQ
How much of the PSPO I covers the Scrum framework?
Scrum.org does not publish weights for its competencies. Five of the twelve listed focus areas sit in this competency, and framework rules also decide many product-management questions, so plan to master it fully.
Is the PSPO I just the PSM I with a different name?
No. Both draw on the Scrum Guide, but Scrum.org says many PSPO I questions focus on the Product Owner accountabilities, so expect more scenarios about backlog ordering, value and stakeholders and fewer about coaching the team.
Can the Product Owner also be a Developer?
The Scrum Guide does not forbid one person holding both accountabilities. Questions usually test whether that person still respects the Developers' self-management and keeps product decisions transparent.
Who attends the Daily Scrum?
The Daily Scrum is an event for the Developers. If the Product Owner is actively working on Sprint Backlog items, they take part as a Developer.
Can the Product Owner change the Sprint Backlog during the Sprint?
The Sprint Backlog belongs to the Developers. The Product Owner can clarify and renegotiate scope with them as more is learned, as long as the Sprint Goal is not endangered.
What is the difference between the Product Goal and a product vision?
The Product Goal is the Scrum Guide commitment for the Product Backlog: one concrete future state of the product. Product vision is a separate focus area in Managing Products with Agility that describes the product's purpose and audience.
How long should I study this competency?
This page uses an editorial estimate of 11 to 14 hours, which assumes an even split of a 30-hour plan across the 12 focus areas. Experienced Scrum practitioners mostly need time for unlearning workplace habits.
Other Agile & Scrum certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 1 knowledge
You have covered empiricism, the Product Owner's accountabilities, the events and artifacts, and the Definition of Done. Check whether you can apply those rules quickly in Product Owner scenarios.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the PSPO I AI tutor Get any concept explained your way