PSPO I — Scrum.org Professional Scrum Product Owner I Quick Review
Quick Review for Scrum.org Professional Scrum Product Owner I (PSPO I): high-yield Scrum, Product Owner accountability, artifacts, events, Done, value, and practice strategy.
Quick Review purpose
This Quick Review is for candidates preparing for the Scrum.org Professional Scrum Product Owner I (PSPO I) exam from Scrum.org, official exam code PSPO I. It is an independent review aid designed to help you refresh the highest-yield Scrum and Product Owner concepts before using topic drills, mock exams, original practice questions, and detailed explanations.
Use this page to check your decision rules. PSPO I questions often test whether you can apply Scrum accountabilities, artifacts, events, and Product Owner value decisions in realistic scenarios—not just recall definitions.
High-yield exam mindset
For PSPO I, think in terms of empiricism, value, accountability, and transparency.
| Concept | What to remember | Common trap |
|---|---|---|
| Scrum | A lightweight framework for solving complex problems through empiricism and lean thinking | Treating Scrum as a project management methodology with fixed phases |
| Empiricism | Decisions are based on transparency, inspection, and adaptation | Making hidden decisions outside the Product Backlog or Sprint events |
| Product Owner | Accountable for maximizing product value and effective Product Backlog management | Treating the Product Owner as a task manager or stakeholder secretary |
| Scrum Team | One team with Product Owner, Scrum Master, and Developers; no sub-teams or hierarchy | Creating separate “business,” “QA,” “architecture,” or “management” sub-teams inside Scrum |
| Value | Measured by outcomes, learning, customer impact, and business results—not just output | Assuming more completed backlog items automatically means more value |
| Done | A usable Increment must meet the Definition of Done | Counting incomplete work as “almost done” or “accepted later” |
Scrum foundations to know cold
Empiricism and lean thinking
Scrum is built on:
| Pillar | Practical meaning |
|---|---|
| Transparency | Work, progress, quality, and product state must be visible and understandable |
| Inspection | Scrum Teams and stakeholders inspect artifacts, progress, and outcomes frequently |
| Adaptation | If reality differs from expectations, adjust the plan, Product Backlog, process, or goals |
Lean thinking reinforces focus on essentials and reduction of waste. On exam questions, avoid answers that create unnecessary process, handoffs, documentation gates, or approval layers.
Scrum values
| Value | Exam-relevant interpretation |
|---|---|
| Commitment | Commit to goals, quality, and collaboration—not fixed scope at all costs |
| Focus | Focus on the Sprint Goal and valuable product outcomes |
| Openness | Make work, problems, progress, and uncertainty visible |
| Respect | Trust people as capable professionals |
| Courage | Surface hard truths, challenge assumptions, and adapt when needed |
A strong PSPO I answer usually supports transparency and professional accountability rather than command-and-control behavior.
Scrum accountabilities
Scrum has three accountabilities: Product Owner, Scrum Master, and Developers.
| Accountability | Primary accountability | Key exam points |
|---|---|---|
| Product Owner | Maximizing product value and effective Product Backlog management | One person, not a committee; may delegate work but remains accountable; orders the Product Backlog; communicates the Product Goal |
| Scrum Master | Establishing Scrum as defined in the Scrum Guide | Serves the Scrum Team, Product Owner, and organization; helps remove impediments; coaches Scrum adoption |
| Developers | Creating a usable Increment each Sprint | Own the Sprint Backlog; create the plan; adapt daily; are accountable for quality and adherence to the Definition of Done |
Product Owner accountability
The Product Owner is accountable for:
- Maximizing the value of the product resulting from the Scrum Team’s work.
- Developing and explicitly communicating the Product Goal.
- Creating and clearly communicating Product Backlog items.
- Ordering Product Backlog items.
- Ensuring the Product Backlog is transparent, visible, and understood.
The Product Owner may delegate Product Backlog management activities, but accountability remains with the Product Owner.
One Product Owner, many stakeholder voices
The Product Owner is one person, not a committee. Stakeholders, customers, users, executives, regulators, sales teams, support teams, and Developers may all influence product decisions, but those wanting changes to Product Backlog ordering must work through the Product Owner.
| Situation | Scrum-consistent response |
|---|---|
| Stakeholders disagree about priority | Product Owner listens, balances value, risk, learning, and strategy, then orders the Product Backlog |
| Executive wants Developers to start urgent work directly | Request should be made transparent and handled through Product Owner/Product Backlog decisions |
| Product Owner delegates backlog writing | Acceptable, but Product Owner remains accountable for Product Backlog effectiveness |
| Committee wants to “own” the Product Backlog | Incorrect in Scrum; the Product Owner is one person |
Scrum artifacts and commitments
Each Scrum artifact has a commitment that improves transparency.
| Artifact | Purpose | Commitment | High-yield point |
|---|---|---|---|
| Product Backlog | Ordered, emergent list of what is needed to improve the product | Product Goal | The Product Owner is accountable for ordering and transparency |
| Sprint Backlog | Sprint Goal, selected Product Backlog items, and plan for delivering them | Sprint Goal | Owned and adapted by Developers during the Sprint |
| Increment | A concrete stepping stone toward the Product Goal | Definition of Done | Must be usable and meet the Definition of Done |
Product Backlog
The Product Backlog is:
- Ordered.
- Emergent.
- Transparent.
- The single source of work undertaken by the Scrum Team for the product.
- Refined as more is learned.
Higher-ordered Product Backlog items are usually clearer and more refined than lower-ordered items. Refinement can include adding detail, splitting items, estimating, clarifying acceptance considerations, and reordering.
Product Goal
The Product Goal describes a future state of the product and provides long-term direction. The Scrum Team should focus on one Product Goal at a time; it is either fulfilled or abandoned before taking on another Product Goal.
Common exam trap: confusing the Product Goal with the Sprint Goal.
| Goal | Time horizon | Owned/accountable through | Purpose |
|---|---|---|---|
| Product Goal | Longer-term product objective | Product Backlog commitment | Guides product direction |
| Sprint Goal | Current Sprint objective | Sprint Backlog commitment | Guides the Sprint and provides flexibility around scope |
Sprint Backlog
The Sprint Backlog includes:
- The Sprint Goal.
- Product Backlog items selected for the Sprint.
- The Developers’ plan for delivering the Increment.
The Developers own the Sprint Backlog. The Product Owner does not assign Sprint Backlog tasks or control the Developers’ plan.
Increment and Definition of Done
An Increment is usable only when it meets the Definition of Done. Work that does not meet the Definition of Done is not part of the Increment.
| Rule | Exam implication |
|---|---|
| An Increment must be usable | “Almost done” is not enough |
| Work must meet the Definition of Done | Undone work cannot be counted as completed |
| Multiple Increments may be created during a Sprint | Scrum does not require only one Increment at the end |
| Release can occur before Sprint end | Sprint Review is not a release gate |
| Multiple Scrum Teams on one product need an integrated Increment | They must coordinate around the same product and a shared Definition of Done |
Scrum events quick review
Scrum events create regular opportunities for inspection and adaptation.
| Event | Participants / ownership | Purpose | Key trap |
|---|---|---|---|
| Sprint | Whole Scrum Team | Container for all other events; creates a Done Increment | Treating Sprint as a mini-waterfall phase |
| Sprint Planning | Whole Scrum Team | Decide why the Sprint is valuable, what can be Done, and how work will be approached | Product Owner assigns work |
| Daily Scrum | Developers | Inspect progress toward Sprint Goal and adapt the plan | Status meeting for Scrum Master or Product Owner |
| Sprint Review | Scrum Team and stakeholders | Inspect the outcome and adapt the Product Backlog | Formal sign-off or demo-only meeting |
| Sprint Retrospective | Scrum Team | Inspect how the team worked and plan improvements | Optional “lessons learned” afterthought |
Sprint
A Sprint is a fixed-length event of one month or less. A new Sprint starts immediately after the previous Sprint concludes.
During the Sprint:
- No changes are made that would endanger the Sprint Goal.
- Quality does not decrease.
- The Product Backlog may be refined as needed.
- Scope may be clarified and renegotiated with the Product Owner as more is learned.
Sprint Planning
Sprint Planning answers three questions:
| Topic | Question | Main accountability |
|---|---|---|
| Why? | Why is this Sprint valuable? | Product Owner proposes value; Scrum Team collaborates on Sprint Goal |
| What? | What can be Done this Sprint? | Developers select work in collaboration with Product Owner |
| How? | How will selected work be delivered? | Developers create the plan |
The Product Owner should ensure attendees are prepared to discuss the most important Product Backlog items and how they support the Product Goal.
Daily Scrum
The Daily Scrum is for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.
Good exam answers avoid these misconceptions:
- It is not a status report to the Scrum Master.
- It does not require the three traditional questions.
- It is not where the Product Owner assigns work.
- It is not the only time Developers may adapt their plan.
Sprint Review
The Sprint Review is about inspecting the product outcome and adapting the Product Backlog. It is not merely a demonstration.
Stakeholders provide feedback, market or organizational changes may be discussed, and the Product Backlog may be adjusted. The review should improve transparency about progress toward the Product Goal.
Sprint Retrospective
The Sprint Retrospective inspects the Scrum Team’s effectiveness, interactions, processes, tools, and Definition of Done. Improvements may be added to the Sprint Backlog for the next Sprint when appropriate.
Common trap: thinking the retrospective is optional if the Sprint went well. It is a Scrum event and supports continuous improvement.
Product Owner decision rules
Use these decision rules when answering scenario questions.
| Question | Scrum-consistent answer |
|---|---|
| Who orders the Product Backlog? | Product Owner |
| Who can change Product Backlog order? | Product Owner is accountable; others may influence |
| Who owns the Sprint Backlog? | Developers |
| Who decides how much work to select for a Sprint? | Developers, in collaboration with the Product Owner |
| Who creates the plan for the Sprint? | Developers |
| Who defines the Sprint Goal? | Scrum Team collaboratively during Sprint Planning |
| Who can cancel a Sprint? | Product Owner, if the Sprint Goal becomes obsolete |
| Who is accountable for product value? | Product Owner |
| Who is accountable for establishing Scrum? | Scrum Master |
| Who is accountable for creating a usable Increment? | Developers |
| Who manages stakeholders? | Product Owner collaborates with stakeholders; Scrum Master may help with Scrum understanding |
| Who estimates Product Backlog items? | Developers who will do the work |
| Who ensures the Product Backlog is transparent and understood? | Product Owner |
Product Backlog management traps
| Trap answer | Why it is wrong | Better reasoning |
|---|---|---|
| “The Product Backlog is a fixed requirements document” | Scrum expects emergence and learning | Product Backlog evolves as more is learned |
| “The highest-paid stakeholder decides priority” | Scrum has one Product Owner accountable for ordering | Stakeholders influence; Product Owner decides ordering |
| “Developers must complete all selected Sprint items” | The commitment is to the Sprint Goal, not fixed scope | Scope can be negotiated if the Sprint Goal remains intact |
| “The Product Owner assigns tasks” | Developers manage their own plan | Product Owner clarifies value and backlog items |
| “Definition of Ready is required by Scrum” | It is not a Scrum artifact or commitment | Teams may use helpful practices, but they are not Scrum requirements |
| “Velocity is a commitment” | Velocity is a planning aid, not a promise | Use empirical evidence without turning it into a contract |
| “Sprint Review is acceptance testing” | Review is inspection/adaptation with stakeholders | Done work should already meet the Definition of Done |
| “Only testers are responsible for quality” | Developers are accountable for quality | Quality is built into the Increment through the Definition of Done |
Sprint change scenarios
New urgent request appears during the Sprint
Ask:
- Does the request affect the Sprint Goal?
- Is it more important than current Sprint work?
- Can the Developers adapt the Sprint Backlog without reducing quality?
- Does the Product Owner agree that the change improves value?
| If… | Then… |
|---|---|
| The request does not endanger the Sprint Goal | Product Owner and Developers may negotiate Sprint Backlog changes |
| The request makes the Sprint Goal obsolete | Product Owner may cancel the Sprint |
| The request is important but not urgent | Add/order it in the Product Backlog for future consideration |
| The request requires lowering quality | Do not lower quality; adapt scope or ordering instead |
Work is not finished by Sprint end
Do not call it Done. Do not include it in the Increment. Return unfinished work to the Product Backlog for reordering if it is still valuable.
Stakeholder demands a mid-Sprint scope change
Stakeholders should not directly control Developers’ Sprint work. The Product Owner collaborates with stakeholders and Developers to determine the best value-based response.
Value, outcomes, and product thinking
The Product Owner is not just a backlog administrator. PSPO I preparation should emphasize product value and outcome thinking.
| Output-focused thinking | Outcome-focused thinking |
|---|---|
| “We delivered 20 items” | “What customer, user, or business result improved?” |
| “The roadmap says this feature is next” | “Is this still the most valuable thing to learn or deliver?” |
| “Stakeholders requested it” | “What value, risk, cost, or learning justifies it?” |
| “The team is busy” | “Is the Scrum Team creating valuable Done Increments?” |
Product Owners should consider:
- Customer and user needs.
- Business value.
- Risk reduction.
- Market learning.
- Technical sustainability.
- Cost of delay.
- Dependencies.
- Strategic fit with the Product Goal.
A high-value Product Backlog is not just a ranked wish list. It is an empirical decision tool.
Definition of Done review
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
| Situation | Correct interpretation |
|---|---|
| Work passes coding but not testing | Not Done unless testing is outside the Definition of Done, which would weaken transparency |
| Product Backlog item is partially complete | Not part of the Increment |
| Organization has required standards | The Scrum Team must follow them as a minimum |
| Multiple Scrum Teams work on one product | They must use a shared Definition of Done for the integrated Increment |
| Team wants stricter quality criteria | A team may apply higher standards |
Common mistake: treating the Definition of Done as optional acceptance criteria. Acceptance criteria may help clarify a Product Backlog item, but the Definition of Done applies to the Increment’s quality and usability.
Multiple Scrum Teams on one product
If multiple Scrum Teams work on the same product:
- There is one product.
- There is one Product Backlog.
- There is one Product Owner.
- Work must integrate into one Increment.
- Teams need a shared Definition of Done.
- Coordination should support transparency and value, not create unnecessary management layers.
Avoid answers that create separate Product Owners, separate Product Backlogs for the same product, or unintegrated team outputs.
Product Owner collaboration patterns
| Collaboration area | Product Owner focus |
|---|---|
| With Developers | Clarify value, order, goals, and Product Backlog items; respect Developers’ technical plan |
| With Scrum Master | Improve Scrum understanding, empiricism, stakeholder collaboration, and Product Backlog management |
| With stakeholders | Gather input, explain decisions, manage expectations, and make trade-offs transparent |
| With users/customers | Validate needs, outcomes, usability, and value assumptions |
| With organization | Help align funding, governance, strategy, and product decision-making with empirical delivery |
A good Product Owner is available enough to support fast learning and decision-making, but does not micromanage how Developers build the Increment.
Common PSPO I candidate mistakes
Mistake 1: Memorizing terms without applying accountability
Many questions are scenario-based. If a question asks who decides, who owns, or who is accountable, return to the Scrum accountabilities.
Mistake 2: Treating the Product Owner as a project manager
The Product Owner does not assign tasks, manage individual performance, or force Developers to commit to fixed scope. The Product Owner maximizes value through product decisions and Product Backlog management.
Mistake 3: Confusing commitment with fixed scope
The Sprint Goal is the commitment. The selected Product Backlog items are a forecast and can be adapted if needed.
Mistake 4: Lowering quality to hit a date
Scrum does not support reducing quality to meet a scope commitment. Adapt scope, ordering, or expectations instead.
Mistake 5: Making Sprint Review a sign-off gate
The Sprint Review inspects the Increment and adapts the Product Backlog. Work should already meet the Definition of Done before it is considered Done.
Mistake 6: Adding non-Scrum roles as required
Scrum does not require project managers, business analysts, architects, testers, release managers, or team leads as formal Scrum accountabilities. People may have skills or job titles, but Scrum defines only Product Owner, Scrum Master, and Developers.
Mistake 7: Assuming the Scrum Master is the team manager
The Scrum Master is accountable for establishing Scrum and serving the Scrum Team and organization. The Scrum Master does not command the Developers or override the Product Owner’s product decisions.
Fast review tables
Artifact-to-question mapping
| If the question is about… | Think first about… |
|---|---|
| Product direction | Product Goal |
| Backlog order | Product Owner accountability |
| Sprint purpose | Sprint Goal |
| Daily adaptation | Developers and Sprint Backlog |
| Product quality | Definition of Done |
| Stakeholder feedback | Sprint Review |
| Team process improvement | Sprint Retrospective |
| Value maximization | Product Owner decisions and empirical evidence |
| Incomplete work | Not Done; not part of Increment |
Event-to-inspection mapping
| Event | Inspects | Adapts |
|---|---|---|
| Sprint Planning | Product Backlog, Product Goal, capacity, past performance | Sprint Goal, selected work, initial plan |
| Daily Scrum | Progress toward Sprint Goal | Sprint Backlog and daily plan |
| Sprint Review | Increment, market/product conditions, progress toward Product Goal | Product Backlog |
| Sprint Retrospective | Team effectiveness, quality, process, tools, interactions | Improvement plan |
“Best answer” clues
| Wording clue | Likely direction |
|---|---|
| “Who is accountable?” | Choose the Scrum accountability, not a committee |
| “Stakeholder demands…” | Product Owner considers input but remains accountable for ordering |
| “During the Sprint…” | Protect Sprint Goal and quality; adapt scope if needed |
| “Incomplete work…” | Not Done, not part of Increment |
| “Developers are waiting for direction…” | Developers self-manage their plan |
| “Scrum Master tells the team…” | Prefer coaching, facilitation, and Scrum understanding over command |
| “Release at Sprint Review…” | Release is not gated by Sprint Review |
| “Need more certainty…” | Use transparency, inspection, adaptation—not heavy upfront control |
Independent practice strategy
After this Quick Review, use PM Mastery practice to convert recognition into exam-ready decision-making.
| Practice step | What to do | What to look for in explanations |
|---|---|---|
| Topic drills | Start with Product Owner accountability, Product Backlog, artifacts, and events | Why one answer fits Scrum accountabilities better than plausible alternatives |
| Mixed original practice questions | Mix Scrum framework and product ownership scenarios | Whether you can identify the governing Scrum rule quickly |
| Mock exams | Practice under realistic pressure | Patterns in missed questions, especially wording traps |
| Detailed explanations | Review every missed or guessed answer | The decision rule you should apply next time |
| Retake weak-topic drills | Focus only on weak areas | Improved speed and confidence without memorizing question wording |
Use the question bank as a diagnostic tool. If you miss a question, classify the miss:
- Accountabilities error.
- Artifact/commitment confusion.
- Event purpose confusion.
- Product Owner vs stakeholder decision error.
- Done/quality misunderstanding.
- Value/outcome reasoning gap.
- Overcomplicated process answer.
Final pre-practice checklist
Before starting a mock exam or timed topic drill, confirm you can answer these quickly:
- What is the Product Owner accountable for?
- Who owns the Product Backlog order?
- Who owns the Sprint Backlog?
- What is the difference between Product Goal and Sprint Goal?
- What makes an Increment usable?
- What happens to unfinished work?
- Why is Sprint Review not a sign-off meeting?
- Why is Daily Scrum not a status meeting?
- When can a Sprint be canceled?
- What changes are allowed during a Sprint?
- How do multiple Scrum Teams work on one product?
- Why is value more than output?
Practical next step
Start with a focused PSPO I topic drill on Product Owner accountability and Product Backlog management, then review the detailed explanations for every missed or uncertain answer. After that, move into mixed original practice questions and mock exams to test whether you can apply Scrum rules under exam-style pressure.
Continue in PM Mastery
Use this Quick Review as a final concept map, then move into PM Mastery for focused topic drills, mixed practice sets, timed mock exams, and detailed explanations. The practice questions are original PM Mastery practice items; they are not official Scrum.org questions, copied live-exam content, or exam dumps.