Overview
This competency holds six of the twelve PSPO I focus areas: Forecasting & Release Planning, Product Vision, Product Value, Product Backlog Management, Business Strategy, and Stakeholders & Customers. Together they describe how a Product Owner connects the organization's mission to the work the Developers pull each Sprint, and how evidence from each Increment changes the next decision.
Candidates must understand a chain of intent from business strategy to product vision to the Product Goal and Sprint Goal, and the feedback loop that runs back up it. They must judge value by outcomes for customers and the organization rather than by output, order the Product Backlog with the whole product in view, forecast from real data, and release in small steps. The framework rules about Increments, Done and the Sprint Review supply the mechanics this competency puts to work.
How it's tested
Questions are mostly Product Owner scenarios asking for the best or most valuable action, with some multiple-answer items about measures or ordering factors. Distractors look like sound management practice. The reasoning is to prefer evidence over opinion, outcomes over output, small releases over big ones, and decisions the Product Owner makes transparently through the Product Backlog.
-
Best evidence of value
Several measures are offered and you pick the one that reflects outcomes for customers or the organization, such as usage, satisfaction or revenue, over activity measures like velocity.
-
Stakeholder pressure
A stakeholder demands a change, a date or a direct line to the Developers. You choose the response that keeps one ordered Product Backlog and transparent trade-offs.
-
Forecast under uncertainty
A date or scope question asks how to plan. The answer uses past empirical data, ranges and frequent releases, and updates the forecast as Increments arrive.
Sales asks the Product Owner to promise five features by a trade show in three months. Options include committing to the date, adding Developers, or forecasting from the team's actual throughput and offering a range. Ask what evidence exists: past Sprints. Ask what keeps transparency: an honest forecast, ordering so the most valuable items land first, and releasing early. The best answer forecasts from data and orders for value, not a fixed promise.
Focus areas 6
Official focus areas from the Scrum.org outline, in outline order.
3.1 Forecasting & Release PlanningForecasting from evidence and releasing value in small, frequent steps.
- What it means
- Forecasting uses what has already happened, such as completed Product Backlog items per Sprint, to predict likely outcomes; release planning decides how and when Increments reach users. Scrum.org frames this as small, frequent releases rather than big-bang launches.
- What to understand
- Burn-downs, burn-ups and cumulative flow diagrams help, but the Scrum Guide says they do not replace empiricism, and only past data can inform forward-looking decisions in complex work. Forecasts are ranges that change as each Increment produces new evidence. A Done Increment can be released at any time, including before the Sprint Review, and choosing when to release is a value decision for the Product Owner.
- How it shows up
- A stakeholder wants a fixed date and fixed scope, or a long project plan is proposed, and you choose the empirical approach.
- Common confusion
- Candidates treat a forecast as a commitment. A forecast is a probability-based prediction that the Product Owner keeps updating and communicating, not a promise the Developers must meet.
3.2 Product VisionA product's purpose: what value it should deliver and to whom.
- What it means
- The product vision describes why the product exists, who it serves and what it should change for them. It gives direction that is longer-lived than any Product Goal and helps everyone judge whether an idea belongs in the product.
- What to understand
- The vision is not a Scrum Guide artifact, but a Product Owner uses it to derive Product Goals and to say no to items that do not serve it. A good vision is short, shared and understood by Developers and stakeholders alike, so they can make aligned decisions without asking.
- How it shows up
- A team builds features that each make sense alone but do not add up, or stakeholders disagree about direction, and you pick the action that restores a shared purpose.
- Common confusion
- Candidates confuse the vision with the Product Goal. The vision describes enduring purpose; the Product Goal is one concrete future state the Scrum Team works toward next.
3.3 Product ValueDelivering value to customers and stakeholders and measuring it by outcomes.
- What it means
- Value is the benefit customers, users and the organization actually receive from the product. Scrum.org ties it to the Scrum Team's objective and teaches it through Evidence-Based Management (EBM), whose four Key Value Areas are Current Value, Unrealized Value, Time to Market and Ability to Innovate.
- What to understand
- Output measures such as velocity, items completed or hours worked show activity, not value. Outcome measures such as customer satisfaction, usage of new features, revenue per user or reduced support calls show whether the product helps. Technical debt matters to the Product Owner because it lowers Ability to Innovate and slows Time to Market.
- How it shows up
- A question lists candidate metrics or asks how a Product Owner should prove the product is improving.
- Common confusion
- Candidates pick rising velocity as proof of value. Velocity, if a team tracks it, is a planning aid that varies by team and says nothing about whether customers benefit.
3.4 Product Backlog ManagementCreating, refining and ordering Product Backlog items toward the Product Goal.
- What it means
- Product Backlog management means keeping one ordered, emergent, transparent list of the changes the product may need, with items refined until they are ready for selection in Sprint Planning. Its content and order are the Product Owner's to decide.
- What to understand
- Order reflects the Product Owner's judgment of value, risk, dependencies and learning; the Scrum Guide does not mandate a formula. Items near the top are smaller and clearer than those further down. Refinement is an ongoing activity, often done with the Developers, who size the items. Anyone can propose items, but they enter the product only through the Product Owner's ordering.
- How it shows up
- Scenarios describe a bloated backlog, separate backlogs for each team, or a stakeholder adding items directly at the top.
- Common confusion
- Candidates equate ordering with assigning priority labels such as high, medium and low. Scrum asks for a single order, which forces explicit trade-offs that labels hide.
3.5 Business StrategyHow the organization's mission and strategy shape product visions and goals.
- What it means
- Business strategy describes how the organization intends to achieve its mission, and it informs each product's vision. The Product Owner translates that strategy into product decisions and brings evidence from the market back to inform the strategy.
- What to understand
- Strategy, vision, Product Goal and Sprint Goal form a chain where each level narrows the one above. Evidence from Increments flows back up, so a Product Owner may adapt goals or propose strategic changes when data contradicts assumptions. Product Owners also weigh the cost of building against the expected return, since every Sprint is an investment.
- How it shows up
- A question describes a product that meets its feature list but no longer fits a changed company strategy, and asks what the Product Owner should do.
- Common confusion
- Candidates think strategy is fixed once set. In an empirical approach, product evidence is meant to test and refine strategic assumptions.
3.6 Stakeholders & CustomersWorking closely with stakeholders, and customers in particular, to discover and validate value.
- What it means
- Customers use or pay for the product; stakeholders are anyone with an interest in it, such as executives, support staff or regulators. Scrum.org stresses frequent collaboration with both, and especially with customers, because their behavior and feedback reveal whether the product delivers value.
- What to understand
- The Sprint Review is the formal point where key stakeholders inspect the Increment with the Scrum Team and help adapt the Product Backlog, but collaboration happens throughout the Sprint as well. The Product Owner represents stakeholder needs in the Product Backlog and makes trade-offs visible; the Developers may talk with stakeholders directly to understand items. The Scrum Master helps facilitate stakeholder collaboration when needed.
- How it shows up
- A powerful stakeholder bypasses the Product Owner, or stakeholders skip the Sprint Review, and you pick the response that restores collaboration and transparency.
- Common confusion
- Candidates treat the Product Owner as the only person allowed to speak to stakeholders. The Product Owner owns the decisions, not every conversation.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Evidence-Based Management (EBM)
EBM is Scrum.org's framework for measuring and improving value using evidence, organized into four Key Value Areas: Current Value, Unrealized Value, Time to Market and Ability to Innovate.
- Remember
- It measures outcomes and capability, not team activity, and is used to set and inspect goals.
- Tested as
- Questions on how a Product Owner demonstrates or improves value lean on this way of thinking.
- Trap
- Treating EBM as a team productivity scorecard and comparing teams with it.
-
Current Value vs. Unrealized Value
Current Value is the value the product delivers today; Unrealized Value is the potential value that could be gained by better meeting customer needs.
- Remember
- A product can be strong today and still have large unmet opportunity, or the reverse.
- Tested as
- Scenarios about whether to invest further in a mature product use this distinction.
- Trap
- Assuming high current revenue means there is nothing left to gain.
-
Time to Market and Ability to Innovate
Time to Market reflects how quickly the organization can deliver and learn; Ability to Innovate reflects how freely it can deliver new capability rather than maintenance.
- Remember
- Technical debt and slow releases reduce both, which is why quality is a Product Owner concern.
- Tested as
- Questions about technical debt or long release cycles from a value angle.
- Trap
- Thinking technical debt is purely the Developers' problem with no product impact.
-
Outcome over output
Outcomes are changes in customer behavior or business results; outputs are features, items or story points produced.
- Remember
- The Product Owner maximizes value, so outcomes are the measure of success.
- Tested as
- Metric-choice questions where velocity or feature count appear as options.
- Trap
- Selecting increased velocity as proof that the product is more valuable.
-
Product definition
The Scrum Guide describes a product as a vehicle to deliver value with a clear boundary, known stakeholders and well-defined users or customers.
- Remember
- A product may be a service, a physical product or something more abstract; defining it sets the scope of one Product Backlog.
- Tested as
- Questions about how many Product Owners or backlogs a group of teams needs.
- Trap
- Defining products by component or team, which splits value across many backlogs.
-
Forecasting from empirical data
Forecasts use completed work from past Sprints to project likely outcomes, often as ranges.
- Remember
- Burn-downs, burn-ups and cumulative flow help but do not replace empiricism, and only what has already happened can inform forward decisions.
- Tested as
- Date-and-scope questions with stakeholders.
- Trap
- Using estimates of unstarted work as if they were evidence.
-
Release decisions
A Done Increment can be released whenever it creates value, including several times within a Sprint.
- Remember
- Small, frequent releases shorten feedback loops and reduce risk compared with big-bang launches.
- Tested as
- Questions about holding releases until the Sprint Review or until all features are ready.
- Trap
- Believing the end of the Sprint or the Sprint Review is the only release point.
-
Ordering, not prioritizing
The Product Backlog has a single order that reflects the Product Owner's judgment of value, risk, dependencies and learning.
- Remember
- No formula is mandated; the Product Owner may use any technique but remains accountable.
- Tested as
- Questions about tied priorities or stakeholders demanding top position.
- Trap
- Using high/medium/low labels so several items share the top spot.
-
Strategy to Sprint Goal chain
Business strategy informs the product vision, which informs the Product Goal, which shapes each Sprint Goal.
- Remember
- Evidence travels back up the chain and can change goals or strategy.
- Tested as
- Alignment questions where work does not connect to the organization's direction.
- Trap
- Assuming direction only flows downward and never adapts.
-
Stakeholders at the Sprint Review
Key stakeholders are invited to the Sprint Review to inspect the Increment and help adapt the Product Backlog.
- Remember
- It is a collaborative working session, and stakeholder input is also welcome between Reviews.
- Tested as
- Questions about stakeholders who stop attending or only want slide presentations.
- Trap
- Replacing the Review with a status report sent by email.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Business strategy vs. product vision vs. Product Goal vs. Sprint Goal
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Business strategy | How the organization plans to achieve its mission | Spans products and sets direction for them | Treating it as fixed once approved |
| Product vision | The product's purpose: what value it delivers and to whom | Long-lived and not a Scrum Guide artifact | Using it as a list of features |
| Product Goal | One concrete future state of the product; commitment for the Product Backlog | The Scrum Team works toward one at a time | Confusing it with the vision or with a Sprint Goal |
| Sprint Goal | The one objective of a Sprint; commitment for the Sprint Backlog | Crafted by the whole Scrum Team at Sprint Planning | Writing it as a list of all selected items |
Output measures vs. outcome measures
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Output measures | Velocity, items completed, features shipped | Show how much was produced, not whether it helped anyone | Using them to prove value or compare teams |
| Outcome measures | Customer satisfaction, feature usage, revenue, cycle time to customers | Show whether the product changed results for customers or the organization | Ignoring them because they take longer to collect |
Customers vs. users vs. stakeholders
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Customers | Those who buy or choose the product | Their decisions show whether the product is worth paying for | Assuming the customer is always the person using it |
| Users | Those who interact with the product | Their behavior shows whether the product is usable and useful | Treating internal users as stakeholders only |
| Stakeholders | Anyone with an interest in the product, such as executives, support or legal | They influence the Product Backlog through the Product Owner | Letting them add items directly or order the backlog |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Velocity as value
- What candidates pick
- The Product Owner reports that value increased because velocity rose by 20%.
- Why it looks right
- Velocity is familiar and easy to chart.
- Why it's wrong
- Velocity measures output and is team-specific; value shows in outcomes such as usage, satisfaction or revenue.
Clue to watch for The question asks about value, benefit or success for customers.
-
Fixed-date, fixed-scope promise
- What candidates pick
- The Product Owner commits to delivering every requested feature by the launch date.
- Why it looks right
- It satisfies the stakeholder and sounds accountable.
- Why it's wrong
- Complex work makes scope and date uncertain; the Product Owner forecasts from past data, orders for value and adapts as Increments arrive.
Clue to watch for A date and a full feature list requested together with no evidence offered.
-
Stakeholder adds work directly
- What candidates pick
- A director places an urgent item at the top of the Product Backlog and tells the Developers to start.
- Why it looks right
- The director is senior and the item may matter.
- Why it's wrong
- The Product Owner is accountable for Product Backlog order; the director should persuade the Product Owner, who weighs the item against the Sprint Goal and other work.
Clue to watch for Someone other than the Product Owner changing order or directing the Developers.
-
Big-bang release
- What candidates pick
- The Product Owner waits until all features are Done before releasing anything.
- Why it looks right
- One launch feels cleaner for marketing.
- Why it's wrong
- Delaying release delays feedback and value; small, frequent releases let the Product Owner learn what customers actually use.
Clue to watch for Done Increments sitting unreleased while customers wait.
-
Product Owner as sole contact
- What candidates pick
- The Product Owner forbids Developers from speaking with users to avoid distraction.
- Why it looks right
- It looks like protecting the team's focus.
- Why it's wrong
- Collaboration with stakeholders and customers improves understanding; the Product Owner keeps decision authority without blocking conversations.
Clue to watch for Developers who need clarification that only users can give.
-
Many backlogs for one product
- What candidates pick
- Each of three teams on one product keeps its own Product Backlog and Product Owner.
- Why it looks right
- Smaller backlogs look easier to manage.
- Why it's wrong
- One product has one Product Backlog and one Product Owner so value trade-offs are made across the whole product.
Clue to watch for Several teams working on the same product with separate priorities.
-
Ignoring technical debt
- What candidates pick
- The Product Owner always orders new features above quality work.
- Why it looks right
- Features are visible to customers and stakeholders.
- Why it's wrong
- Accumulated technical debt slows Time to Market and Ability to Innovate, reducing future value; it is a product trade-off the Product Owner must weigh.
Clue to watch for A team reporting that changes take longer every Sprint.
Answer framework
Apply these steps to PSPO I questions about value, planning and stakeholders.
- Identify the value question behind the scenario: who benefits, and what outcome would show that they did.
- Prefer options that use evidence from released Increments or past Sprints over opinions, estimates or seniority.
- Check that the decision flows through one ordered Product Backlog owned by the Product Owner, with trade-offs made transparent to stakeholders.
- Favor small, frequent releases and ranged forecasts over fixed promises and big-bang launches, updating plans as new data arrives.
- Confirm the choice fits the chain from business strategy to product vision to Product Goal, and reject options measured only by output such as velocity or features shipped.
Practice question
Want more like this? The PSPO I practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Study the focus areas in an order that follows the chain of intent: Business Strategy, Product Vision, Product Value, Product Backlog Management, Forecasting & Release Planning, then Stakeholders & Customers. Each one builds on the previous, and the last pulls them together in realistic scenarios.
Give most time to Product Value and Product Backlog Management. Learn the Evidence-Based Management Key Value Areas from Scrum.org's EBM Guide and practice sorting metrics into outputs and outcomes until it is automatic. For the backlog, be clear on who orders, who sizes, how refinement works and why one product has one Product Backlog. Commonly underestimated areas are forecasting language (ranges and past data, not commitments), the fact that releases need not wait for the Sprint Review, and technical debt as a value issue.
Afterwards, practice scenario questions where every option sounds like reasonable management. For each, ask which option uses evidence, keeps one ordered backlog and puts outcomes first. Then return to timed full-length practice, since this competency's scenarios take longer to read than framework rule checks.
FAQ
Is Managing Products with Agility the largest part of the PSPO I?
Scrum.org does not publish weights, but six of the twelve focus areas sit here and Scrum.org says many questions focus on the Product Owner accountabilities. Treat it as a major area.
Do I need to know Evidence-Based Management for the PSPO I?
EBM is not named on the PSPO I page, but it is Scrum.org's framework for the Product Value focus area. Knowing the four Key Value Areas helps you reason about value questions.
Who decides when to release?
A Done Increment can be released whenever it adds value. Deciding whether and when is a product value decision for the Product Owner, often made with stakeholders.
What is the difference between a forecast and a commitment?
A forecast predicts likely outcomes from past data and changes as new evidence arrives. The Developers commit to the Sprint Goal, not to a forecast of future scope.
Can stakeholders talk directly to the Developers?
Yes. Collaboration with stakeholders and customers is encouraged, but changes to the Product Backlog's content or order go through the Product Owner.
Does the Product Owner have to write every Product Backlog item?
No. Others, including Developers, may create and refine items, but the Product Owner remains accountable for the Product Backlog's content and order.
How much study time does this competency need?
This page's editorial estimate is 13 to 17 hours, based on an even split of a 30-hour plan across the 12 focus areas. Candidates without product-management experience may need more.
Other Agile & Scrum certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 3 knowledge
You have covered forecasting, vision, value, backlog management, strategy and stakeholder work. Test whether you can choose outcome evidence and transparent trade-offs under exam time.
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