Try 45 free SAFe POPM questions across the exam domains, with answers and explanations, then continue in PM Mastery.
This free full-length SAFe POPM practice exam includes 45 original PM Mastery questions across the exam domains.
The questions are original PM Mastery practice questions aligned to the exam outline. They are not official exam questions and are not copied from any exam sponsor.
Count note: this page uses a 45-question PM Mastery full-length practice format for the POPM route. Scaled Agile’s current public POPM page lists 90 minutes and an 82% passing score; confirm current exam count, timing, passing score, and renewal rules directly with Scaled Agile.
Set a 90-minute timer and answer all 45 questions before reading explanations. Track misses by product ownership, backlog/value decisions, PI planning, stakeholder alignment, or ART flow.
Use this page as a POPM diagnostic, not as the only measure of readiness. The most useful result is the pattern behind your misses.
| Result pattern | What it usually means | Next step |
|---|---|---|
| Strong score and misses are scattered | Your SAFe product-role model may be stable. Review explanations and protect timing. | |
| Many role misses | Revisit Product Owner versus Product Manager responsibilities and how they coordinate with teams and the ART. | |
| Many PI Planning misses | Drill vision, features, dependencies, risks, PI objectives, and business value conversations. | |
| Many iteration or PI execution misses | Review stories, team backlog, flow, PO Sync, System Demo, and Inspect and Adapt. | |
| AI-related misses feel superficial | Tie AI use to backlog quality, prioritization, discovery, stakeholder communication, and responsible oversight. |
| Field | Record |
|---|---|
| Overall score | ___ / 45 questions |
| Timing result | Finished early / on time / rushed late |
| Highest-miss area | product roles / PI planning prep / PI planning leadership / iteration execution / PI execution / AI |
| Most expensive mistake type | role confusion / weak feature logic / poor dependency handling / flow anti-pattern / other: ___ |
This static page is useful for one diagnostic pass. PM Mastery is better for repeated practice because it gives you varied timed attempts, focused POPM drills, explanations, and progress history instead of one page you can memorize.
| Checkpoint | Approximate time budget | What to do |
|---|---|---|
| Questions 1-15 | 30 minutes | Keep Product Owner and Product Manager responsibilities separate. |
| Questions 16-30 | 60 minutes cumulative | Watch for PI Planning, dependency, and feature-readiness traps. |
| Questions 31-45 | 90 minutes cumulative | Finish with enough time to review marked flow and AI-augmented product-role items. |
If you retake this free diagnostic, treat the second attempt as a reasoning check rather than a fresh score. Give more weight to varied timed attempts in PM Mastery than to repeating one static page.
| Item | Detail |
|---|---|
| Issuer | Scaled Agile |
| Exam route | SAFe POPM |
| Official exam name | AI-Empowered SAFe Product Owner/Product Manager (POPM) |
| Full-length set on this page | 45 questions |
| Exam time | 90 minutes |
| Topic areas represented | 6 |
| Topic | Approximate official weight | Questions used |
|---|---|---|
| POPM Roles and Responsibilities | 13% | 6 |
| PI Planning Preparation | 18% | 8 |
| Leadership for PI Planning | 15% | 7 |
| Iteration Execution | 29% | 13 |
| PI Execution | 11% | 5 |
| Apply AI to Product Roles | 14% | 6 |
Topic: PI Planning Preparation
A Product Manager uses AI to cluster customer feedback before PI Planning, then validates the drafts with support data and team estimates. The ART has room for one new feature this PI, and the card-service API dependency will be ready in Iteration 2.
Exhibit:
1. Improve app security.
Source: 3 survey comments; no clear capability or size.
2. Let customers freeze and unfreeze a card in the mobile app.
Evidence: 18% of support calls are about lost cards.
Dependency: Card-service API ready in Iteration 2.
Size: One ART can deliver it this PI.
3. Add inline error text to the reset-password page.
Scope: One team estimates it fits in one iteration.
4. Modernize identity and payments across web and mobile.
Scope: Three ARTs over 18 months.
Which item should be prioritized into the ART Backlog as a feature for this PI?
Best answer: D
What this tests: PI Planning Preparation
Explanation: A SAFe feature should describe a stakeholder-valued capability that one ART can complete in a PI. The card freeze/unfreeze item is specific, evidence-backed, dependency-aware, and sized appropriately, so it is the best-ready feature candidate for the ART Backlog.
In SAFe, a feature is a service or capability that fulfills a stakeholder need and can be completed by one ART in one PI. The card freeze/unfreeze item fits that definition: it expresses clear customer value, has supporting evidence from support-call data, identifies a dependency, and is sized for this ART and PI.
By contrast, a vague request lacks enough clarity for backlog readiness, a small UI change is more like a story for a team backlog, and a multi-ART, 18-month modernization effort is too large and uncertain for a single feature. AI can help draft candidates, but the Product Manager still must validate evidence, scope, and readiness before prioritizing ART-level work.
It is a clear customer-valued capability with evidence, a known dependency, and sizing that fits one ART within one PI.
Topic: Apply AI to Product Roles
A Product Manager and the Product Owners on an ART have one week before PI Planning. They must turn recent customer feedback into refined backlog items, identify likely dependencies, and send a stakeholder update. The notes include sensitive customer details, and the teams have not confirmed capacity. What is the best action?
Best answer: D
What this tests: Apply AI to Product Roles
Explanation: The best use of AI here is as an assistant across several PO/PM workflows, not as the decision-maker. Sanitizing inputs protects sensitive data, and human review keeps backlog changes, dependency handling, and PI preparation aligned to evidence, strategy, and capacity.
In SAFe POPM work, AI can help Product Managers and Product Owners move faster in discovery, analysis, backlog refinement, PI preparation, and communication. In this scenario, the strongest action is to use AI on sanitized information to summarize customer themes, draft refined backlog content, surface possible dependencies, and prepare a stakeholder update. Then the PM and POs must validate that output against customer evidence, product strategy, ART priorities, dependencies, and actual team capacity before changing backlog items or making commitments.
AI is augmenting the workflow, not replacing accountability. That matters because sensitive data must be protected, and PI commitments cannot be delegated to a tool or finalized before capacity and dependency checks are complete. The closest distractors either hand decision rights to AI or reject useful augmentation entirely.
This uses AI to accelerate discovery, analysis, refinement, and communication while preserving privacy and human product accountability.
Topic: Leadership for PI Planning
During PI Planning, a team adds this dependency note to its board:
Need data-masking service from another team for customer export feature.
As the Product Owner, what is the best interpretation of this note?
Best answer: D
What this tests: Leadership for PI Planning
Explanation: A useful dependency note must support decisions, not just visibility. This note names needed work, but it does not say who provides it, when it is needed, or how delay would affect sequencing or the PI Objective.
In SAFe PI Planning, a dependency note should help teams make immediate planning choices. Here, the note only states that another team must provide a data-masking service. It does not identify the provider team or owner, the needed-by iteration or milestone, or the consequence if the dependency slips.
A stronger dependency note would clarify:
Without that information, the team can see that a dependency exists, but it cannot confidently sequence work, analyze risk, or decide whether the PI Objective should stay committed or become uncommitted.
The note identifies a dependency but lacks owner, timing, impact, and sequencing detail needed to assess risk and adjust PI Objectives.
Topic: Iteration Execution
A Product Owner reviews mid-iteration signals for an Agile Team. In yesterday’s stakeholder review, users said the planned export enhancement is not useful without an approval-status filter. The next two stories in Ready are export stories, but neither includes that need.
Exhibit:
Ready: 2 stories
In progress: 6 stories
Blocked: 2 stories
Review: 1 story
Pattern: blocked items often need story clarification
What is the best response?
Best answer: A
What this tests: Iteration Execution
Explanation: The Product Owner should use stakeholder feedback and flow signals to improve the next work entering execution. Updating the upcoming stories and their acceptance criteria addresses the discovered need and reduces more blocking without micromanaging current team work.
In SAFe iteration execution, product roles use evidence from reviews, stakeholder input, and Team Kanban signals to adjust upcoming backlog work so the team pulls clearer, more valuable stories next. Here, the stakeholder feedback changes what “useful” means for the export capability, and the flow pattern shows that unclear stories are already hurting execution. The best response is to refine the upcoming ready stories now, add the approval-status filter as part of the story detail or acceptance criteria, and improve readiness before more work starts.
Changing upcoming backlog work is appropriate; forcing immediate switching or confusing visibility with commitment is not.
This uses execution and feedback evidence to improve upcoming ready work without disrupting the team’s current commitments.
Topic: POPM Roles and Responsibilities
A company has expanded from one Scrum team to an ART with six Agile Teams. A new checkout capability spans three teams and includes several dependencies. A stakeholder asks one person to own roadmap tradeoffs, prioritize the cross-team capability, and also manage each team’s stories. Which response best reflects SAFe POPM responsibilities?
Best answer: A
What this tests: POPM Roles and Responsibilities
Explanation: In SAFe, cross-team capabilities and ART alignment do not collapse into one single-team product owner role. Product Management guides ART-level features, vision, and priorities, while Product Owners focus on team-level stories and backlog readiness.
The core distinction is backlog level and scope of responsibility. When work spans multiple Agile Teams and must stay aligned to the roadmap and ART priorities, that is a Product Manager concern at the ART level. Product Owners then work with their individual teams to refine stories, clarify acceptance criteria, and keep the Team Backlog ready for iteration execution.
In this scenario, asking one person to own both cross-team feature priority and every team’s stories reflects a single-team product ownership mindset, not SAFe role separation. Dependencies increase the need for ART alignment, but they do not transfer product accountability to the RTE or Business Owners. The best SAFe response preserves clear PM and PO boundaries while supporting coordination across teams.
This is the key SAFe distinction: ART-level feature direction belongs to Product Management, while team-level story readiness belongs to Product Owners.
Topic: POPM Roles and Responsibilities
A Product Manager receives an AI-generated suggestion to move a new reporting feature to the top of the ART Backlog after three recent support tickets mention it. The Product Owner notes the team is about to refine next-iteration stories, but there is no customer interview data yet and product telemetry for the workflow is inconclusive. What is the best next step?
Best answer: D
What this tests: POPM Roles and Responsibilities
Explanation: The best next step is to validate the signal before changing priority. In SAFe, Product Owners and Product Managers use evidence, fast feedback, and customer learning to reduce assumption-driven decisions and improve value delivery.
This scenario presents a weak signal: a few support tickets, inconclusive telemetry, and an AI suggestion. That is useful input, but it is not enough to justify changing backlog priority yet. The Lean-Agile mindset favors hypothesis-driven decisions, fast feedback, and customer learning over assumptions.
The right sequence is:
Immediate reprioritization, business-value scoring without validation, or story writing before confirming demand all act too early. AI can help spot patterns, but PO/PM accountability still requires human validation against real customer evidence.
Backlog priorities should change only after the PO and PM validate the signal with evidence and fast customer learning, not on an assumption or tool suggestion alone.
Topic: Leadership for PI Planning
During PI Planning, the Product Manager and Product Owners review this draft plan:
Feature: In-app upgrade
State: Highest business value
Risk: External billing API approval may slip to Iteration 4
Impact: If delivered after Iteration 3, customer launch value drops sharply
Dependency: Two teams depend on this feature
Current PI Objective: Committed launch by Iteration 3
Capacity: Teams are already fully loaded
Feature: Usage alerts
State: Ready and independent
Customer impact: Moderate value this PI
What is the best product-role response?
Best answer: A
What this tests: Leadership for PI Planning
Explanation: When a risk changes feature value timing and PI Objective confidence, POPM should respond by adjusting the plan, not just making the risk more visible. The best response is to re-sequence toward ready work and revise the objective to match uncertainty and capacity reality.
In SAFe, product roles help the ART make realistic PI Planning decisions when risks affect value, sequencing, or confidence. Here, the highest-value feature loses much of its customer value if it arrives late, has an unresolved dependency, and sits on already full team capacity. That means the issue is not just visibility; it changes what is sensible to commit to in the PI.
A better response is to re-sequence toward ready, independent work and update the PI Objective so the plan reflects actual risk and confidence. Product roles should preserve value delivery while making dependencies and uncertainty explicit. Keeping the original commitment would overstate confidence, while adding more work or simply raising priority does not resolve readiness or capacity constraints.
The key takeaway is that risk in PI Planning should drive realistic sequencing and commitment decisions, not just tracking.
This is best because POPM roles should adjust sequencing and PI Objective confidence based on risk, value timing, and realistic capacity.
Topic: PI Planning Preparation
A Product Manager reviews the top of the ART Backlog one week before PI Planning.
1. Self-service billing changes
Rank: 1
Value: "important for Q3"
Dependencies: unknown
Acceptance criteria: none
2. Usage alerts
Rank: 2
Value: reduce support calls by 15%
Dependencies: analytics team
Acceptance criteria: drafted
Which response best prepares teams to discuss capacity, dependencies, and PI Objectives?
Best answer: C
What this tests: PI Planning Preparation
Explanation: The ART Backlog is not sufficiently ready just because work is listed and ranked. The top feature lacks clear value, dependency information, and acceptance criteria, so refinement and possible re-sequencing are needed before teams can plan realistic capacity and PI Objectives.
For PI Planning preparation, top ART Backlog items need more than visibility. They should be prioritized by value, clarified enough for teams to understand the intent, and aligned enough to discuss dependencies, capacity, and draft PI Objectives. Here, the highest-ranked feature is weakly defined: its value is vague, dependencies are unknown, and acceptance criteria are missing. That makes the current ranking unreliable for planning.
A better preparation step is to:
Teams can help during PI Planning, but they should not be forced to plan around unclear, unready top priorities.
The highest-ranked feature is visible but not ready, so it should be clarified and re-evaluated before teams plan capacity and objectives.
Topic: PI Planning Preparation
Three days before PI Planning, several proposed features still have vague customer value, limited business context, and no clear dependency notes. Which preparation action best matches SAFe POPM guidance?
Best answer: B
What this tests: PI Planning Preparation
Explanation: The best preparation action is to improve feature readiness before PI Planning. POPM roles should clarify feature intent, business context, customer value, and dependencies in the ART Backlog so teams can plan realistically.
PI Planning preparation depends on having backlog items ready enough for meaningful planning conversations. When features still lack clear intent, value, context, or dependency information, the right action is to refine them in the ART Backlog before the event. That preparation helps teams estimate, identify dependencies, and form realistic PI Objectives based on better evidence rather than guesswork.
Letting major gaps remain until planning creates avoidable confusion and weak commitments. The key takeaway is that POPM preparation improves readiness before PI Planning rather than shifting unresolved feature-definition work to the event itself.
PI Planning works best when features have enough intent, value, context, and dependency clarity to support realistic planning.
Topic: Apply AI to Product Roles
A Product Manager and several Product Owners used an AI assistant during PI preparation to draft feature splits, story acceptance criteria, and dependency notes. Before expanding the workflow across the ART next PI, leaders want evidence that it improves product-role effectiveness without weakening transparency, validation, human accountability, or ART value delivery. Which evidence best validates that decision?
Best answer: D
What this tests: Apply AI to Product Roles
Explanation: The best validation is evidence that connects AI assistance to improved product work and ART delivery while preserving human decision rights. Human-reviewed backlog changes, confirmed by PO Sync and System Demo feedback, show both effectiveness and responsible use.
For POPM, AI is useful when it augments product work rather than replacing accountability. The strongest validation is not speed, polish, or tool self-reporting; it is evidence that AI-assisted outputs were reviewed by Product Owners and Product Managers, checked against customer and delivery feedback, and improved actual ART execution. In this scenario, PO Sync and System Demo signals matter because they show whether the backlog changes helped teams coordinate dependencies, reduce rework, and deliver value that stakeholders can inspect. That preserves transparency and human accountability while testing whether AI improved the quality of product decisions. Faster drafting or attractive summaries may be helpful, but they do not prove the workflow is aligned to customer value or safe to scale across the ART.
This evidence ties AI use to better ART outcomes while confirming human review, transparency, and validation against real delivery feedback.
Topic: POPM Roles and Responsibilities
A Product Manager is preparing the ART backlog for PI Planning. Value-stream data shows the biggest delay and customer drop-off happen in the manual approval step, not in browsing or pricing. A large feature, “Faster checkout,” includes changes for browsing, pricing, and approval across two teams. Stakeholders want to schedule it late in the PI and release it all at once.
What is the best next step?
Best answer: B
What this tests: POPM Roles and Responsibilities
Explanation: Value-stream awareness should steer work toward the biggest delay in customer value delivery. The best next step is to slice the feature to address that bottleneck first, discuss dependencies immediately, and create an earlier feedback point before committing to a bigger bundled release.
In SAFe, value-stream awareness helps Product Management sequence backlog items by where value is delayed or lost, not just by stakeholder enthusiasm. Here, the evidence already shows that manual approval is the main constraint in the customer flow. The right next move is to focus on that part of the feature first, expose the cross-team dependency before planning locks in, and get feedback early on the slice that could improve flow the most.
The closest distractor is moving the whole feature up the backlog, but priority without slicing and dependency clarity does not improve flow or learning soon enough.
This targets the known value-stream bottleneck first, addresses dependencies before execution, and creates earlier learning before a larger release decision.
Topic: Leadership for PI Planning
Late in PI Planning, a Business Owner urges the ART to mark every draft PI Objective as committed to reassure a strategic customer. The Product Manager wants evidence before changing the objective set. Which evidence best supports keeping some work uncommitted instead of converting everything to committed objectives?
Best answer: D
What this tests: Leadership for PI Planning
Explanation: The best evidence is current PI Planning data showing whether objectives are achievable within known capacity and constraints. If a stretch objective still carries unresolved dependencies or material risk, keeping it uncommitted preserves realism instead of overcommitting to satisfy stakeholders.
PI Objectives should reflect realistic delivery intent for the coming PI, not optimism driven by external pressure. The most useful validation is current evidence from team plans: capacity, dependencies, and known risks. If committed objectives already fit available capacity and additional work still depends on unresolved external support or significant technical uncertainty, that extra work should remain uncommitted. In SAFe, uncommitted objectives are not low-value filler; they are visible goals with higher uncertainty.
Good validation focuses on facts such as:
Stakeholder preference, polished wording, or last PI’s outcome does not replace present-PI feasibility evidence.
This is the strongest validation because committed objectives should be realistic, while uncertain work with unresolved dependencies or risks belongs in uncommitted objectives.
Topic: Apply AI to Product Roles
A Product Owner wants AI help refine a story that is not yet Ready before iteration planning.
Exhibit:
Story: As an account admin, I can export monthly usage data.
State: Draft
Issue: Acceptance criteria are vague; privacy review may apply.
Need: A better story proposal for Agile Team and Product Manager review.
Which prompt is the best next step?
Best answer: B
What this tests: Apply AI to Product Roles
Explanation: Effective product-role prompts tell the AI what role to play, what work item it is handling, what output is needed, and what limits and checks apply. Here, the best prompt supports story refinement without confusing visibility, priority, or assumption-based readiness.
For AI-assisted backlog refinement, the strongest prompt frames the task the way a Product Owner would: give the AI a role, the story context, the immediate goal, and the boundaries for useful output. In this scenario, the story is still draft quality, privacy review may matter, and the output is meant for Agile Team and Product Manager review rather than automatic acceptance into planning.
A good prompt should specify:
The key takeaway is that AI can improve readiness, but it should not set priority, assume approvals, or declare work committed.
It gives the AI a role, context, goal, constraints, audience, desired output, and explicit validation criteria for a backlog-refinement task.
Topic: PI Execution
During Iteration 3, an Agile Team starts an AI upsell suggestions experiment after hearing a customer idea. The work uses three developers for five days, is not on the Team Backlog or Team Kanban, has no defined learning goal, and may delay a committed PI Objective. As the Product Owner, what is the best interpretation and response?
Best answer: C
What this tests: PI Execution
Explanation: This is not well-managed innovation yet; it is hidden work consuming capacity without visibility, a learning objective, or explicit impact review. In SAFe, innovation is encouraged, but it still needs transparent flow management and alignment with PI commitments.
The key distinction is between intentional innovation and unmanaged side work. Innovation throughout the PI is valid when it is visible, purposeful, and handled transparently; hidden work that consumes capacity and risks a committed PI Objective is a management problem, not a healthy innovation practice.
A better response is to:
The closest trap is treating prototype activity as normal feature delivery, because learning work is not the same as completed stakeholder value.
Innovation work should be explicit, timeboxed, and aligned so learning does not silently displace committed PI work.
Topic: PI Planning Preparation
A Product Manager reviews the PI Planning preparation checklist one week before the event.
Constraints:
ART Backlog lists feature names and sizes.What is the best action?
Best answer: A
What this tests: PI Planning Preparation
Explanation: The checklist is missing core product inputs that help teams make good planning decisions. PI Planning preparation is not just logistics and capacity; it must also give teams enough context about vision, value, priority, and dependencies to create realistic, aligned plans.
For PI Planning readiness, teams need more than feature names, sizes, and event logistics. Product roles should ensure the solution vision, feature priorities, customer value context, and key dependencies are clear before planning starts. Those inputs help teams understand why the work matters, how it supports the roadmap, what should come first, and where coordination risks may affect feasibility.
Without that product context, teams may still produce plans, but the plans are more likely to be misaligned, overcommitted, or weakly connected to customer value. Capacity estimates and architecture notes support planning, but they do not replace product guidance. The best preparation step is to strengthen the checklist with the missing product-readiness evidence before declaring the ART ready for PI Planning.
The key takeaway is that PI Planning readiness depends on product context as well as logistics and capacity.
Teams need vision, priorities, value context, and dependencies to plan work that is valuable, feasible, and aligned.
Topic: Iteration Execution
An Agile Team is starting iteration planning. The top story supports a committed PI Objective, but the team says the user value is unclear, the acceptance criteria are incomplete, and delivery depends on another team’s API update. The team asks whether to include it in the iteration. As the Product Owner, what is the best next step?
Best answer: C
What this tests: Iteration Execution
Explanation: The best next step is to remove the planning blockers before the team commits. In SAFe, the Product Owner supports iteration planning by clarifying priority, value, story intent, acceptance criteria, and dependencies so the team can make a realistic plan aligned to PI Objectives.
Iteration planning works best when the highest-priority stories are understood well enough for the team to assess feasibility and capacity. In this scenario, the team cannot make a sound planning decision yet because the story’s value is unclear, its acceptance criteria are incomplete, and an external dependency may affect delivery timing. The Product Owner should first clarify the intent and expected value, refine the acceptance criteria with the team, and confirm the dependency with the other team or Product Owner. Once that information is known, the Agile Team can estimate, select work, and form an iteration goal that still supports the PI Objective.
Planning the story first and fixing details later risks an unrealistic commitment.
The PO should make the highest-priority work clear and feasible before the team decides whether to plan it into the iteration.
Topic: Apply AI to Product Roles
During PI Planning preparation, a Product Manager wants AI to turn customer interview notes into draft feature summaries. The raw notes include customer names, negotiated pricing, account-specific usage data, and one internal roadmap date. The ART only needs common pain points, desired outcomes, and constraints. What is the best next step?
Best answer: D
What this tests: Apply AI to Product Roles
Explanation: The best next step is to minimize data exposure before using AI. The Product Manager should remove sensitive information and give AI only the non-sensitive context needed to structure useful draft summaries, then review the output before using it.
Responsible AI use in POPM means protecting sensitive information at the input stage, not trying to fix the problem after it has already been shared. Here, the ART only needs generalized pain points, outcomes, and constraints, so the Product Manager should first create a sanitized version of the notes and use that as the prompt context.
The tempting alternative of deleting a conversation later still fails because the sensitive data was exposed when it was entered.
Protecting privacy starts before prompting, so the product role should remove sensitive data and use only necessary, non-sensitive context for AI drafting.
Topic: POPM Roles and Responsibilities
A Product Manager is preparing the ART Backlog for PI Planning next week. A senior stakeholder asks to add a new feature to the roadmap immediately, but the request has no clear customer problem, no supporting feedback, and would likely push out a ready feature with known demand. What is the best POPM response?
Best answer: A
What this tests: POPM Roles and Responsibilities
Explanation: When a request does not clearly connect to customer value, the best POPM action is to validate the need and expected outcome before changing priorities. In SAFe, roadmap and ART Backlog decisions should stay aligned to vision, value, and evidence rather than stakeholder pressure alone.
The core concept is customer-value alignment. In SAFe, a Product Manager should not treat a stakeholder request as backlog truth just because it is urgent or senior-sponsored. If the request lacks a clear customer problem, expected benefit, or fit to the solution vision and roadmap, the next step is to clarify and validate those points before prioritizing it against other work.
A sound POPM response is to confirm:
Estimating size can help later, but size does not create value. Likewise, facilitation roles do not replace product accountability. The key takeaway is that POPM should connect proposed work to customer value before committing roadmap or backlog space.
POPM should validate a request’s customer value and alignment before adding or reprioritizing ART-level work.
Topic: PI Execution
During the IP Iteration, a Product Manager reviews an innovation experiment before the next PI Planning.
Hypothesis: Faster renewal will reduce customer drop-off
Test: 12 customer sessions with a clickable prototype
Result: 9 users completed renewal without help; average time fell 40%
ART impact: aligns to top ART priority "retain existing customers"
Needed follow-up: identity-team enabler; feature not yet sized
What is the best response?
Best answer: B
What this tests: PI Execution
Explanation: This experiment produced actionable learning because it linked evidence from customers to a clear value outcome and an ART priority. The right response is to turn that learning into planning input by preparing an ART-level backlog item with its dependency and success measure.
Innovation work in SAFe is valuable when it creates learning that can change backlog, priority, or planning decisions. Here, the experiment did more than create visibility: it tested a customer-value hypothesis, produced evidence from users, connected to a stated ART priority, and exposed a dependency that matters for planning.
The best next step is to use that learning to shape upcoming PI decisions:
The closest distractor confuses useful evidence with delivery commitment; validated learning can inform prioritization before the work is fully ready for team execution.
The experiment produced actionable learning tied to customer value and ART priorities, so it should inform ART-level planning with its dependency made explicit.
Topic: Apply AI to Product Roles
A Product Owner uses an AI assistant to turn a feature into stories before backlog refinement. After the first draft, the team says the stories are too large, acceptance criteria are vague, and one example includes sensitive customer data. Refinement starts in 30 minutes, and the team needs iteration-sized stories in a consistent format. What is the best next action?
Best answer: B
What this tests: Apply AI to Product Roles
Explanation: The best action is to improve the prompt with specific feedback from the first output. For POPM work, effective prompting means adding examples, constraints, and explicit evaluation criteria so the next draft is more usable and safer before human review.
When AI output is weak, Product Owners and Product Managers should refine the prompt instead of simply rerunning it or accepting rework downstream. In this case, the first draft revealed clear gaps: story size, vague acceptance criteria, inconsistent format, and sensitive data risk. The better response is to update the prompt with product context, one or more examples of good stories, constraints such as iteration-sized scope and no sensitive data, and explicit evaluation criteria for what “good” looks like.
This creates a repeatable AI-assisted refinement practice, unlike options that rely on guesswork, expose data, or defer quality problems to the team.
This is best because it uses iterative prompting with feedback, examples, constraints, and explicit quality checks while preserving human review and data protection.
Topic: PI Execution
During the PO Sync, one team reports a dependency will slip by one iteration. The delay puts a PI Objective at risk, and two Product Owners disagree on whether the affected feature should remain the top ART priority. The Product Manager is available. Which response best matches the purpose of the PO Sync?
Best answer: B
What this tests: PI Execution
Explanation: The PO Sync is an ART-level coordination event for Product Owners and Product Management to address cross-team dependencies, priority conflicts, and PI Objective risk. When a delay affects shared value delivery, the right response is to align on priority and adjust plans immediately rather than defer or localize the decision.
The core concept is ART-level product coordination during PI execution. When a dependency delay threatens a PI Objective and creates a feature-priority conflict, the PO Sync is the place to make the impact visible, get Product Manager clarification on priority, and coordinate changes across affected teams. That keeps backlog decisions aligned to value delivery instead of allowing separate local decisions.
A good POPM response in this situation is to:
The key takeaway is that PO Sync supports fast cross-team alignment on product decisions during the PI, not delayed review or role handoff.
PO Sync is used to coordinate ART-level priorities, dependencies, and PI Objective risks with Product Management and affected Product Owners.
Topic: POPM Roles and Responsibilities
Just before PI Planning, a Product Owner receives a sales request for a new market-facing capability. The PO must decide whether to keep it in the Team Backlog or route it to the Product Manager for ART-level handling. Which evidence best validates routing it to the Product Manager?
Best answer: C
What this tests: POPM Roles and Responsibilities
Explanation: The strongest validation is evidence that the request is ART-level work tied to business intent and spanning multiple teams. That points to feature management and ART alignment, which are Product Manager responsibilities in SAFe.
In SAFe, the Product Manager is responsible for ART-level value alignment: connecting customer and business needs to the vision, roadmap, and ART Backlog. Evidence that the request is already framed as a feature, tied to roadmap value, and dependent on multiple teams shows it needs ART-level prioritization and coordination before team execution.
A Product Owner primarily owns the Team Backlog and helps the team execute well-defined stories. Signals such as clear acceptance criteria for one team or available Team Kanban capacity support team-level readiness, not ART-level ownership. Retrospective input is useful for improvement, but it does not establish whether a request belongs in the Team Backlog or ART Backlog.
The key validation is whether the work represents a feature needing cross-team and business alignment.
Roadmap linkage and cross-team dependencies show ART-level feature work, which fits Product Manager responsibility.
Topic: PI Planning Preparation
A Product Owner is preparing the Team Backlog for PI Planning. The Product Manager has shared this solution vision: “Enable customers to self-schedule service visits the same day.”
Exhibit:
Story: Add calendar-slot API filter
Linked feature: Self-scheduling
Status: Draft
Acceptance criteria: None
Team feedback: "We can build it, but why is this needed now?"
What is the best next action for the Product Owner?
Best answer: A
What this tests: PI Planning Preparation
Explanation: The Product Owner should use solution vision context to refine the Team Backlog before PI Planning. That means making the story understandable in business terms, connecting it to the feature, and clarifying acceptance so the team knows why the work matters.
In SAFe, the Product Owner helps the team understand the value and intent behind planned work by translating higher-level product direction into clear, ready stories. Here, the team already has a draft story, but it lacks user-value framing and acceptance criteria, and the team does not understand why it is important now. The best response is to refine the story using the solution vision and its linked feature so the work is both meaningful and ready for planning.
A good PO response is to:
Visibility alone does not create understanding, and priority alone does not make a story ready. Facilitation support from the RTE also does not replace PO ownership of Team Backlog clarity.
This uses the solution vision to make the story understandable and ready so the team sees both its purpose and its acceptance conditions.
Topic: Leadership for PI Planning
During PI Planning, a Product Manager learns that a high-value feature depends on an interface from another ART. That ART says the interface is only likely by Iteration 4, but the feature’s integration is expected in the PI System Demo and is the main content of a committed PI Objective. What is the best POPM response?
Best answer: A
What this tests: Leadership for PI Planning
Explanation: When a dependency threatens feature completion and demo integration, POPM should improve realism, not hide the risk. The best response is to coordinate sequencing, expose the dependency, and adjust the PI Objective so commitments match current evidence and uncertainty.
In SAFe, dependencies discovered during PI Planning should be made explicit and managed before teams lock in unrealistic commitments. The product roles should preserve value delivery by separating what can proceed independently from what truly depends on the other ART, then coordinate with the dependency owner and update the plan.
This approach balances value, capacity, flow, and accountability. It is better than keeping an unrealistic commitment, abandoning value too early, or treating a tool recommendation as a substitute for human validation.
This keeps value moving while making the dependency visible and the PI Objective realistic before commitments are finalized.
Topic: POPM Roles and Responsibilities
A Product Manager is preparing a short rationale for why the ART should prioritize a new onboarding feature in the next PI. Based on the evidence below, which explanation best reflects strong POPM thinking?
Value stream: Open new account
Current issue: 38% of applicants abandon at ID upload
Pilot: Guided photo capture cut upload retries by 30%
PI goal: Raise onboarding completion from 62% to 72%
Dependency: Security review API available in Iteration 2
Capacity: ART can take one onboarding feature this PI
AI use: Draft summary came from anonymized support/chat data and must be validated
Best answer: D
What this tests: POPM Roles and Responsibilities
Explanation: A strong POPM explanation links the work to a real customer problem, a measurable outcome, and realistic ART execution conditions. It also treats AI as decision support that must be validated, not as the source of product truth.
The best explanation shows end-to-end product thinking. It connects the feature to a specific point of customer friction in the account-opening value stream, uses pilot evidence instead of opinion, and defines success with a measurable outcome: improving onboarding completion from 62% to 72%.
It also stays grounded in ART execution reality:
Explanations based only on complaints, utilization, or feature size optimize locally. POPM explanations should tie customer value, flow, evidence, and execution constraints together.
It is the only explanation that connects customer value, measurable outcome, ART execution reality, value-stream impact, and validated AI-assisted evidence.
Topic: PI Planning Preparation
A Product Manager is preparing the ART Backlog for PI Planning. A senior stakeholder wants Feature A committed because an AI-generated market summary predicts strong demand.
Exhibit:
Feature A: Partner onboarding improvements
- Value statement: "increase growth"
- Acceptance context: not defined
- Dependency: external identity service date unconfirmed
- Stakeholders: Sales and Compliance disagree on scope
Feature B: Self-service invoice download
- Value: reduce support calls by 20%
- Acceptance context: reviewed with team and support
- Dependency: none
- Stakeholders: aligned
What should the Product Manager do next?
Best answer: B
What this tests: PI Planning Preparation
Explanation: PI Planning readiness requires more than perceived urgency. The best choice is to commit the feature with clear value, acceptance context, and no dependency blockage, while treating the vague and disputed feature as preparation work rather than committed delivery.
The key concept is PI Planning readiness. A feature should enter commitment discussions with clear stakeholder value, enough acceptance context for teams to plan, and known dependencies or risks that are understood well enough to forecast delivery. In this scenario, Feature B has evidence of value, reviewed acceptance context, and no dependency issue. Feature A does not: its value is vague, stakeholders disagree, its dependency is unresolved, and the AI summary is only an input that still requires human validation.
A sound POPM tradeoff is to:
The closest distractor is planning both features, but that spreads capacity across work that is not ready and weakens flow and predictability.
Feature B is ready for commitment, while Feature A still lacks clear value, acceptance context, stakeholder alignment, and a resolved dependency.
Topic: Iteration Execution
A Product Owner says, “Release timing is only an operations decision. We’ll wait until the end of the PI for customer feedback, and we can ignore rising escaped defects if planned stories are finished.” Which DevOps support anti-pattern is this?
Best answer: B
What this tests: Iteration Execution
Explanation: The description matches a DevOps support anti-pattern: handing release to technical roles alone, postponing feedback, and ignoring quality signals. In SAFe, POPM supports Release on Demand by staying engaged with value delivery, learning, and quality throughout the PI.
The core concept is shared responsibility for DevOps and Release on Demand at product-role depth. Product Owners and Product Managers do not treat release as only a technical handoff; they help connect business timing, customer feedback, and quality information to backlog and delivery decisions. Waiting until the end of the PI for all feedback slows learning, increases risk, and reduces the ability to adjust scope or priorities. Ignoring escaped defects or other quality signals is also an anti-pattern because quality affects customer value and release decisions.
Good POPM behavior is to use ongoing feedback and quality data during iteration and PI execution, then refine backlog items and priorities accordingly. The closest distractors describe healthy practices, not anti-patterns.
This is the anti-pattern because POPM roles share responsibility for value delivery, fast feedback, and attention to quality signals.
Topic: PI Planning Preparation
Before PI Planning, a Product Manager shares this ART note:
Solution vision: Improve onboarding speed and account trust
Candidate features:
- Guided signup flow (ready)
- Fraud alert dashboard (needs dependency review)
- Admin audit export (requested by one stakeholder)
Roadmap timing: forecast for upcoming PI
A Business Owner says, “Great—this means all three items are promised this PI.” What is the best response?
Best answer: D
What this tests: PI Planning Preparation
Explanation: The solution vision gives shared direction and intended value before PI Planning; it is not a delivery contract. Features still need validation for readiness, dependencies, and capacity before teams and Business Owners align on realistic PI objectives.
In SAFe, the solution vision is used to communicate product direction so the ART enters PI Planning with a shared understanding of the problem, desired outcomes, and likely feature focus. It is not a promise that every item shown will be delivered in the PI. In this scenario, one feature is ready, one still has dependency questions, and one is only a stakeholder request, so the right next step is to use PI Planning to evaluate feasibility and form realistic PI commitments.
A good product-role response is to:
The closest trap is treating roadmap or vision content as guaranteed delivery rather than forecasted direction.
A solution vision communicates intended value and direction, while actual PI commitments are determined through readiness, dependencies, and capacity in PI Planning.
Topic: Leadership for PI Planning
During PI Planning breakout, two teams stop planning because a feature’s value is unclear, an API dependency is unresolved, and planned leave reduces capacity. Stakeholders ask the RTE to settle the argument so teams can keep moving. As the Product Manager, what is the best action?
Best answer: A
What this tests: Leadership for PI Planning
Explanation: The best POPM response is to lead the product decision, not hand it to the RTE or delay it. In PI Planning, the Product Manager should clarify value with Business Owners, work through dependencies with the teams, and adjust scope so commitments match real capacity.
This situation calls for product-role leadership during PI Planning. When planning stalls because value is unclear, priorities conflict, dependencies are unresolved, or capacity is tight, the Product Manager and Product Owners help restore alignment by clarifying business value, confirming priority, exposing dependency impacts, and reducing or resequencing scope to fit available capacity. That keeps PI Objectives realistic and value-focused.
The closest trap is handing the decision to the RTE, but the RTE facilitates the event rather than owning product value or backlog priority.
POPMs should clarify value, align priorities, address dependencies, and adjust scope to realistic capacity before teams commit PI Objectives.
Topic: Leadership for PI Planning
During PI Planning, a Product Manager reviews one team’s draft PI Objectives. Which draft is the strongest PI Objective for the PI?
Best answer: D
What this tests: Leadership for PI Planning
Explanation: A strong PI Objective describes a meaningful business outcome, not just work to be done. The best statement ties delivery to customer or business value and acknowledges a key dependency, which makes the commitment more realistic.
In SAFe, PI Objectives should express what value the team intends to deliver in the PI, not just a list of features, tasks, or hopeful promises. The strongest option focuses on an outcome customers or the business will notice, connects that outcome to support-call reduction, and makes the carrier API dependency visible. That improves alignment and helps Business Owners judge value and realism.
Good PI Objectives usually:
The closest distractor is the feature-and-test list, but that describes activity, not the objective’s value.
It states a business outcome, links the work to value, and realistically calls out a dependency that affects the commitment.
Topic: PI Execution
Midway through the PI, an ART is in PO Sync.
- Team Orion says a dependency story for Feature A will slip one iteration.
- Feature A supports two teams' PI objectives.
- Recent System Demo feedback suggests Feature B could be reduced with little customer impact.
- Business Owners want an updated PI objective outlook today.
What is the best next step?
Best answer: C
What this tests: PI Execution
Explanation: The best next step is to use the PO Sync to align the affected Product Owners, Product Manager, and stakeholders on the dependency impact and any scope tradeoff. That keeps PI objective forecasting evidence-based and coordinated across the ART.
PO Sync helps Product Owners, Product Managers, and ART stakeholders inspect PI execution at the ART level. Here, a delayed dependency affects multiple teams’ PI objectives, and System Demo feedback creates a possible scope tradeoff. The right next step is to review that impact together, update the risk, and decide whether scope should shift so PI objective forecasts stay realistic.
Waiting, reprioritizing immediately, or relying on local team replanning would skip the coordination purpose of the PO Sync.
PO Sync is the place to coordinate cross-team dependency, scope, risk, and PI objective impacts before teams or stakeholders make separate changes.
Topic: Iteration Execution
During the Iteration Retrospective, a team reports that several stories spilled over because acceptance criteria were clarified mid-iteration and stakeholder feedback arrived after development started. This happened in the last two iterations, and next iteration includes a cross-team dependency. As the Product Owner, what is the best action?
Best answer: C
What this tests: Iteration Execution
Explanation: A Product Owner should actively participate in the retrospective by contributing product-related insight and helping the team improve readiness, clarity, and feedback loops. The key is to support a team-owned improvement, not to turn the event into command-and-control or backlog governance.
In SAFe, the Product Owner participates in the Iteration Retrospective as a partner in improvement, especially when product clarity, story readiness, collaboration, and feedback timing are affecting flow. Here, the repeated spillover points to a backlog-readiness problem: acceptance criteria are arriving too late, and stakeholder input is not coming soon enough. The best Product Owner response is to help the team identify a practical improvement for the next iteration, such as clarifying acceptance criteria earlier in refinement and arranging earlier stakeholder feedback.
This keeps the retrospective focused on learning and improvement while respecting role boundaries. The team still owns how it improves, and the Product Owner contributes where product definition and stakeholder alignment directly affect delivery flow. The closest trap is stepping back entirely; that avoids overreach, but it also neglects an important Product Owner responsibility.
This supports team-owned improvement by addressing story readiness, feedback timing, and product clarity without the Product Owner taking over the retrospective.
Topic: Iteration Execution
An Agile Team’s Team Kanban shows stories frequently moving to Blocked after development starts because priority changes and business rules are unclear. The Product Owner begins refining upcoming stories with the team, clarifies acceptance criteria, and confirms priority before stories enter Ready. After two iterations, which signal is the best evidence that flow improved?
Ready without reworkBest answer: D
What this tests: Iteration Execution
Explanation: The strongest validation is a flow signal tied to readiness and blocked work. If fewer stories stop for clarification and the team can pull work from Ready without rework, the Product Owner’s refinement and priority decisions are improving flow where the problem occurred.
For this learning objective, the best evidence is not general activity but a direct change in flow behavior on the Team Kanban. The Product Owner improved priority clarity, reduced product ambiguity, and refined upcoming stories before the team started them. The clearest validation is that fewer stories become blocked because questions were answered earlier, and stories selected for the iteration are already ready enough to move without churn.
Good validation signals usually show:
Ready into implementationSignals about stakeholder interest, higher WIP, or faster AI drafting do not directly prove better team flow. The key takeaway is that Product Owners improve flow by making work clear, prioritized, and ready before it enters active delivery.
This directly shows reduced ambiguity and better readiness, which are key Product Owner levers for improving flow.
Topic: Apply AI to Product Roles
A Product Manager uses AI to compare customer feedback themes, summarize recent System Demo notes, and draft new ART Backlog ordering before the next PO Sync. The AI recommends moving a feature ahead of two others.
Which evidence best validates whether that reprioritization decision should be accepted?
Best answer: A
What this tests: Apply AI to Product Roles
Explanation: AI can help synthesize feedback and propose backlog options, but POPM accountability stays with humans. The best validation is evidence that the recommendation fits actual customer need, ART priorities, dependencies, risk, and realistic capacity.
The core concept is responsible AI augmentation of PO/PM work. AI is useful for comparing feedback themes, summarizing demo notes, and drafting backlog options, but it does not become the decision-maker. Before changing ART Backlog priority, the Product Manager should validate the recommendation against the same evidence used for sound SAFe product decisions.
Useful validation includes:
A polished summary or a plausible recommendation is not enough. The key takeaway is that AI can accelerate analysis, but backlog prioritization still requires human review grounded in product evidence and delivery reality.
This is the strongest validation because AI suggestions must be checked against real product evidence and delivery constraints before backlog decisions change.
Topic: Iteration Execution
During iteration planning, the Scrum Master has started the event, the Agile Team is estimating the top ready stories, and reduced capacity means not all candidate stories will fit. The Product Manager has already prioritized the ART Backlog for the PI. What should the Product Owner do next?
Best answer: A
What this tests: Iteration Execution
Explanation: The Product Owner’s next step in iteration planning is to help the team understand which ready stories matter most and how they support an achievable iteration goal. Facilitation belongs to the Scrum Master, estimation belongs to the team, and ART-level prioritization is not the immediate responsibility in this moment.
In SAFe, the Product Owner participates in iteration planning by bringing clarity on value, priority, and intent for the Team Backlog. Here, the planning event is already underway, the Scrum Master is already facilitating, and the team is already estimating. The immediate issue is reduced capacity, so the Product Owner should help the team understand which ready stories best support the iteration goal and should be pulled first.
The closest distractor is shifting to ART-level reprioritization, but the scenario says ART priorities are already set for the PI and the team needs Team Backlog guidance now.
The Product Owner supports iteration planning by clarifying priority and value on the Team Backlog so the team can make a realistic commitment.
Topic: Iteration Execution
A Product Owner is refining the next Team Backlog. In the last System Demo, customers could start a new-order workflow but could not finish it because the error messages were unclear. After the demo, the Product Manager raised that feature on the ART Backlog because it now drives the PI’s most important business outcome. The PO wants to move the story for clearer validation messages ahead of a reporting story. Which evidence best validates that reorder?
Best answer: B
What this tests: Iteration Execution
Explanation: The strongest validation is evidence that users cannot complete a workflow tied to the Product Manager’s highest-priority feature. That directly connects execution feedback and product-value alignment, which is what should drive Team Backlog reorder decisions.
A Product Owner should reorder or clarify the Team Backlog based on validated feedback about value, readiness, and user impact. Here, the most important signal is the System Demo result showing that customers cannot complete a critical workflow, combined with the Product Manager’s updated feature priority on the ART Backlog. That gives the PO concrete evidence that the story improving validation messages should move up because it removes an immediate obstacle to delivering the ART’s highest-value outcome.
Signals like team preference, story size, or unvalidated AI rankings can inform discussion, but they do not outweigh direct demo feedback tied to product priority. The key takeaway is that Team Backlog sequencing should reflect real execution feedback and ART-level value, not convenience alone.
It ties observed user impact from execution directly to the Product Manager’s updated priority, giving the PO the strongest evidence to reorder the Team Backlog.
Topic: PI Execution
At the end of a PI, an ART reviews metrics showing rising cross-team wait time and lower-than-expected customer uptake for a completed feature. Each team has already held iteration retrospectives, and the issue affects multiple teams and future feature planning. As the Product Manager, what is the best next action?
Best answer: A
What this tests: PI Execution
Explanation: This situation is PI-wide, cross-team, and based on both flow metrics and value outcomes, so it belongs in Inspect and Adapt. The right response is to identify systemic causes and turn them into prioritized improvement actions in the backlogs.
Inspect and Adapt is the SAFe event used at the end of a PI to evaluate solution results, review metrics, and address systemic problems that affect ART flow and delivered value. In this scenario, the problem is bigger than one team, has already persisted through iteration-level retrospectives, and requires follow-through that can influence upcoming backlog and planning decisions.
The best action is to use Inspect and Adapt to:
Iteration retrospectives are team-level, System Demos focus on integrated solution feedback, and PO Sync supports ongoing coordination during the PI, not end-of-PI systemic improvement.
Inspect and Adapt is the ART-level event for turning PI-wide flow and value findings into concrete improvement actions and backlog changes.
Topic: Iteration Execution
During iteration planning prep, a Product Owner is slicing a feature for an online billing ART: “Customers can upgrade their plan in the app.” Customer evidence shows the highest near-term value is letting existing subscribers view plan options and upgrade using their saved payment method. Promotional discounts depend on another team’s discount engine and remain uncertain. The team has capacity for three small stories this iteration, and an AI assistant drafted stories using copied customer account examples. What should the Product Owner do next?
Best answer: B
What this tests: Iteration Execution
Explanation: Stories should preserve feature intent by delivering thin slices of customer value that a team can finish within an iteration. The best choice validates the AI draft, protects sensitive data, and focuses this iteration on the highest-value upgrade path while deferring the uncertain dependency.
In SAFe, a feature is translated into stories by slicing along user value, not by copying full scope into one large item or breaking work into technical layers. Here, the clearest proven value is enabling existing subscribers to view plan options and upgrade with their saved payment method. The Product Owner should refine that outcome into small, testable Team Backlog stories, validate any AI-generated content, and remove copied customer data before using it.
Promo-code discounts depend on another team and are still uncertain, so forcing that work into this iteration would reduce flow and increase risk. Stories should stay small enough for one team to complete within the iteration while still expressing customer value. Thin vertical slices preserve the feature’s intent, expose dependencies clearly, and keep accountability with the Product Owner rather than the AI tool.
It turns feature intent into small, valuable, iteration-sized stories while respecting dependency uncertainty, capacity, data protection, and PO accountability.
Topic: PI Planning Preparation
Before PI Planning, a Product Manager wants one view that shows feature priority and another that shows whether each feature is still being analyzed, is ready, or is already moving through delivery. Which distinction best reflects how SAFe uses the ART Backlog and ART Kanban?
Best answer: A
What this tests: PI Planning Preparation
Explanation: In SAFe, the ART Backlog and ART Kanban serve related but different purposes. The backlog is where ART-level work such as features is prioritized and refined, while the Kanban makes work status, readiness, and flow visible across the ART.
The key distinction is ordering/refinement versus flow visualization. The ART Backlog holds and prioritizes features and other ART-level work so the ART can prepare the right items for upcoming planning and delivery. The ART Kanban complements that by showing where those items are in the flow, such as funnel, analysis, backlog, implementing, validating, or done.
This matters before PI Planning because POPM roles need both views:
A common mistake is to swap these purposes. Kanban helps visualize and manage flow; it does not replace backlog prioritization or refinement.
This is correct because the ART Backlog supports prioritization and refinement of ART-level work, while the ART Kanban makes feature status and flow visible.
Topic: Iteration Execution
During Team Backlog refinement, a Product Owner is reviewing this story:
As a customer, I want to update my notification preferences so that I receive only the messages I want.
Which statement is the best example of acceptance criteria for this story?
Best answer: D
What this tests: Iteration Execution
Explanation: Acceptance criteria define testable conditions that show whether a story delivers the intended user value. The correct option describes the expected outcome from the customer’s perspective, not how the team will build it or the broader quality standard applied to all work.
In SAFe iteration execution, acceptance criteria help make a story ready and testable by describing the conditions under which the Product Owner can accept it. Good acceptance criteria focus on observable behavior or outcomes tied to user value. Here, the correct statement explains what must happen for the customer: preferences are saved and used for future notifications after confirmation.
The other choices describe nearby but different concepts:
The key distinction is that acceptance criteria describe what must be true for the story to be accepted, not how to build it or the team’s general completion standard.
This is an acceptance criterion because it states an observable condition the story must satisfy for the user.
Topic: Iteration Execution
During the current iteration review, users say a new reporting workflow is confusing. The same issue appears again in the System Demo, and the Product Manager confirms that improving usability now matters more than a lower-value export story planned for next iteration. In the Team Backlog, the usability stories exist but are still vague and lack acceptance criteria.
What should the Product Owner do next?
Best answer: C
What this tests: Iteration Execution
Explanation: The Product Owner should act on validated feedback from reviews and demos, then use Product Manager input to reorder the Team Backlog. Because the higher-priority usability stories are still unclear, the next step is to refine them with the team so they are ready for upcoming work.
In SAFe, the Product Owner owns Team Backlog clarity and sequencing at the team level. Here, the feedback is strong because the same usability problem appeared in both the iteration review and the System Demo, and the Product Manager has confirmed the priority change. That means the Product Owner should now reorder the Team Backlog to reflect the updated value signal and work with the team to clarify the usability stories before they are pulled into planning or execution.
A good next step is to:
Waiting, starting lower-value work, or committing unclear stories would all skip the readiness step. The key is to combine validated feedback with backlog refinement before execution.
This uses validated execution feedback and Product Manager input to reorder the Team Backlog and make the upcoming stories ready for planning.
Topic: Leadership for PI Planning
During PI Planning, a Product Manager presents a feature that spans two teams. In breakout, one team starts writing stories that optimize an internal workflow rather than the customer outcome. A stakeholder also asks for a last-minute reporting change, and there is still a dependency on a shared API team. What is the best action?
Best answer: D
What this tests: Leadership for PI Planning
Explanation: In SAFe, the Product Manager maintains ART-level alignment by clarifying feature intent, priority, and stakeholder context. The Product Owner then reinforces that vision with the team by refining stories and acceptance criteria so local planning supports the broader ART outcome.
This tests role boundaries during PI Planning. When a team drifts from the intended customer outcome, the Product Manager should restate the feature’s purpose, priority, and stakeholder context at the ART level. The Product Owner then translates that direction into team-level backlog clarity by adjusting stories so the team’s plan supports the feature and its dependencies.
A good sequence is:
The closest distractor is letting the Product Owner reprioritize the ART Backlog, which crosses from team-level ownership into Product Management responsibility.
This keeps ART-level alignment with the Product Manager while the Product Owner reinforces the vision through team-level story clarification.
Topic: Iteration Execution
A Product Manager has a new feature already deployed behind a toggle. Quality signals are acceptable, but pilot customers will not be available to give feedback until next week, so user access is delayed. Which SAFe concept best matches this decision?
Best answer: D
What this tests: Iteration Execution
Explanation: This describes Release on Demand: the feature can be technically deployed, but the business chooses when to release it based on readiness, feedback timing, and customer availability. SAFe separates deployment from release so value can be delivered at the right time.
The core concept is Release on Demand. In SAFe, POPM roles help decide when a deployed capability should actually be made available to users. That decision is influenced by factors such as feature toggles, quality signals, operational constraints, and whether the right customers are available to provide meaningful feedback.
Here, the feature is already deployed, which means the technical act of deployment is complete. The remaining decision is about release timing: waiting until pilot customers are available improves learning and reduces the risk of releasing when feedback cannot be gathered effectively. The closest traps are events or flow tools, but this scenario is specifically about controlling customer exposure for value delivery.
It fits the decision to separate deployment from release and expose the feature when feedback timing and customer readiness support value delivery.
Topic: Iteration Execution
During an iteration retrospective, the team says late story changes caused rework and frustration. Which Product Owner response is the clearest retrospective anti-pattern?
Best answer: A
What this tests: Iteration Execution
Explanation: The anti-pattern is turning feedback into a defense of past product decisions. In a retrospective, the Product Owner should listen, acknowledge impact, and help improve how work is prepared and coordinated.
An iteration retrospective is meant to inspect how the iteration went and identify improvements for future work. Product Owners should participate by listening to team feedback, clarifying where backlog readiness or communication contributed to problems, and supporting experiments that improve flow and quality. Re-arguing that every late change was justified shifts the event away from learning and into self-defense, which discourages honest feedback. In SAFe, the Product Owner contributes to improvement without taking over the team’s retrospective or using it as a forum to prove past decisions were right. The key distinction is improvement-focused participation versus defensive justification.
Retrospectives should enable learning and improvement, not become a defense of every product decision.
Topic: Iteration Execution
During Team Backlog refinement on an ART, a story supporting the “self-service payment update” feature has acceptance criteria such as “update quickly” and “handle errors well.” The team says the criteria are ambiguous, not testable, and missing expired-card edge cases. What is the best Product Owner action?
Best answer: B
What this tests: Iteration Execution
Explanation: The Product Owner should improve the story before the team commits to it. In SAFe, unclear acceptance criteria are a backlog-readiness problem, so the right action is to collaborate with the team to define testable outcomes, include edge cases, and reconnect the story to the feature’s value.
Acceptance criteria help the team understand what must be true for a story to deliver usable customer value. When criteria are vague, untestable, or missing edge cases, the Product Owner should work with the team and relevant stakeholders to refine them before the story is treated as ready. Good criteria describe observable outcomes, cover important boundary conditions such as expired cards, and make it clear how the story supports the feature value.
A practical Product Owner response is to:
Letting the team discover the meaning during development increases rework, while handing it off to testers or bouncing it back to the ART Backlog avoids the PO’s backlog-clarity responsibility.
This fixes story readiness at the source by making acceptance criteria clear, testable, and tied to customer value before the team commits.
Use the SAFe POPM Practice Test page for the full PM Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Use the full PM Mastery practice page above for the latest review links and practice route.