Free SAFE-POPM Practice Test

The first step in SAFe's Continuous Delivery Pipeline is Continuous Exploration (CE). The primary goal of CE is to align on what needs to be built. This process begins with the 'Hypothesize' activity, where Product Owners and Product Managers use design thinking, customer feedback, and market research to identify problems and propose potential solutions. They formulate hypotheses about what features or capabilities will create the most value for customers. This activity drives the creation of the vision, roadmap, and the features that will be developed in subsequent steps of the pipeline.

A. Ensure the Architecture team has sufficient capacity This is typically a responsibility of management or the Release Train Engineer (RTE), not the primary activity of Product Owners/Managers in the exploration phase.
B. Negotiate Supplier contracts This is a business, procurement, or Solution Management function. While Product Management provides input, they do not typically lead contract negotiations.
C. Prioritize the Team Backlog Prioritizing the Team Backlog (which contains Stories) is a key Product Owner responsibility, but it occurs during PI and Iteration Planning, which are part of Continuous Integration, not the initial Continuous Exploration step.

1. Scaled Agile, Inc. (2023). Continuous Exploration. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/continuous-exploration/

Reference Details: The article states, "Continuous Exploration (CE) is the process of continually exploring the market and user needs... It starts with a hypothesis of what will provide value to the customer." It explicitly lists 'Hypothesize' as the first practice within CE.

2. Scaled Agile, Inc. (2023). Continuous Delivery Pipeline. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/continuous-delivery-pipeline/

Reference Details: The overview diagram and description identify Continuous Exploration as the first element of the pipeline, focused on defining hypotheses to be tested.

3. Scaled Agile, Inc. (2023). Product Management. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/product-management/

Reference Details: Under the "Responsibilities" section, it details that Product Management's role is "Understanding customer needs and validating solutions," which is achieved through Continuous Exploration activities like formulating value hypotheses.

The Iteration Retrospective is a dedicated event held at the end of each Iteration for the Agile Team to reflect on its process and identify improvements. This event is a core component of the team-level Inspect and Adapt cycle and directly embodies the SAFe Core Value of Relentless Improvement. During the retrospective, the team analyzes what went well, what did not, and creates an improvement backlog item to action in the next Iteration. This structured, recurring practice ensures continuous, incremental process enhancement at the team level.

A. Inspect and Adapt is a Program Increment (PI) level event for the entire Agile Release Train (ART), not a specific Agile Team event.
B. The System Demo's primary purpose is to provide feedback on the integrated solution from a stakeholder perspective, not to improve the team's internal processes.
D. The Team Sync is a brief daily meeting focused on coordinating the day's activities and tracking progress towards the Iteration Goal, not on process improvement. ---

1. Scaled Agile, Inc. (2023). Iteration Retrospective. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/iteration-retrospective/.

Reference Specifics: The article states, "The Iteration Retrospective is a regular event for the Agile Team to reflect on the Iteration and identify improvements to its process... This is a key part of the team’s Inspect and Adapt (I&A) cycle and directly supports the SAFe Core Value of Relentless Improvement."

2. Scaled Agile, Inc. (2023). Relentless Improvement. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/relentless-improvement/.

Reference Specifics: This article defines Relentless Improvement as a core value and highlights the Inspect and Adapt event as the mechanism for the Agile Release Train, distinguishing it from the team-level retrospective.

3. Scaled Agile, Inc. (2023). Inspect & Adapt. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/inspect-and-adapt/.

Reference Specifics: The first paragraph clearly defines the I&A as an event for the Agile Release Train: "The Inspect and Adapt (I&A) is a significant event held at the end of each Program Increment (PI), where the current state of the Solution is demonstrated and evaluated by the train."

The Vision describes the future state of the Solution and what it will do to meet customer needs. According to the Scaled Agile Framework, a primary input for developing this Vision is direct customer and stakeholder feedback. This aligns with the core SAFe principle of Customer Centricity, which emphasizes understanding and solving customer problems. By gathering feedback through methods like interviews, surveys, and direct observation, Product Management can ensure the Vision is grounded in real-world user needs, thereby guiding the Agile Release Train (ART) to build a valuable and desirable solution.

B. Team topologies: This defines how teams are organized to deliver value; it is an execution consideration, not an input to the solution's strategic direction.
C. Feature context: The Vision provides the context for Features, not the other way around. Features are derived from the Vision to break it down into deliverable increments.
D. Portfolio Backlog: While the Portfolio Backlog's Epics influence the ART's work, customer feedback is a more direct and foundational input that informs both the Portfolio Backlog and the ART Vision.

1. Scaled Agile, Inc. (2023). Vision. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/vision/. In the "Inputs to the Vision" section, "Customer and stakeholder feedback" is listed as the first input.

2. Scaled Agile, Inc. (2023). Customer Centricity. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/customer-centricity/. The article states, "Customer-centric enterprises use market and user research to ensure they understand the problems and the customer’s needs," which directly supports using feedback to shape the solution.

3. Leffingwell, D., et al. (2023). SAFe 6.0 Product Owner/Product Manager Course Workbook. Scaled Agile, Inc. (This is representative of official courseware). Lesson 2, "Preparing for PI Planning," details how the Vision is created, emphasizing the role of customer feedback in defining the problems to be solved and the proposed solution.

In the Scaled Agile Framework (SAFe), a Solution is explicitly defined as a product, service, or system that is delivered to a customer, who can be either internal or external to the enterprise. Solutions are the tangible outcomes of a SAFe portfolio's value streams. They are often large and complex, requiring the coordinated effort of multiple Agile Release Trains (ARTs) and suppliers, which are organized into a Solution Train. The focus is on delivering a complete and valuable offering that meets customer needs.

A. Capability: A Capability represents a higher-level behavior of a Solution. It is a component or a large feature, not the entire delivered product or system itself.
B. Value: Value is the benefit or worth that the customer receives from the Solution. It is the outcome or perception, not the tangible product, service, or system.
D. Epic: An Epic is a container for a significant development initiative. It represents a large-scale business or technology investment, which is then broken down, not the final delivered product. ---

1. Scaled Agile, Inc. (2023). Solution. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/solution/

Reference Point: In the first paragraph, the article states, "Each Value Stream produces one or more Solutions, which are products, services, or systems delivered to the customer, whether internal or external to the Enterprise."

2. Scaled Agile, Inc. (2023). SAFe Glossary. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/glossary/

Reference Point: The glossary entry for "Solution" provides the same definition: "A product, service, or system delivered to the customer, whether internal or external to the Enterprise."

3. Scaled Agile, Inc. (2023). Capability. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/capability/

Reference Point: The first paragraph defines a Capability as "a higher-level solution behavior that typically spans multiple ARTs," distinguishing it from the complete Solution.

4. Scaled Agile, Inc. (2023). Epic. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/epic/

Reference Point: The first paragraph defines an Epic as "a container for a significant Solution development initiative," clarifying its role as an initiative rather than a delivered product.

A primary function of a Kanban board is to make the flow of work visible. A key practice within the Kanban method is to limit Work-in-Process (WIP). Kanban boards implement this by setting explicit limits on the number of items that can be in any given workflow state (column). When a column's WIP limit is reached or exceeded, it provides an immediate and clear visual signal that the team is overloaded in that part of the process. This helps the team identify bottlenecks and manage their workload to improve flow and predictability.

A. The board visualizes work items, but it does not inherently calculate or display the Cost of Delay for each item.
C. The board tracks the flow of work towards completion, not the cumulative business value of the work that has been delivered.
D. A burndown chart is a separate agile metric tool used to track work remaining against time, which is different from a Kanban board's purpose of visualizing flow. ---

1. Scaled Agile, Inc. (2023). "SAFe Team Kanban." Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/safe-team-kanban/. In the section "Establish Work in Process (WIP) Limits," the article states, "WIP limits... create a pull system... When a column reaches its WIP limit, the team swarms to help the work items in that column move to the next state." This directly supports that the board demonstrates where WIP is too high.

2. Scaled Agile, Inc. (2023). "Principle #6 – Make value flow without interruptions." Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/make-value-flow-without-interruptions/. This principle's section on "Limiting work in process (WIP)" explains, "When there is too much WIP, there is inherent friction, task switching, and overhead." The Kanban board is the primary tool for visualizing and managing these WIP limits.

The Product Owner (PO) is fundamentally responsible for maximizing the value delivered by the Agile team. A key aspect of this is ensuring the product meets quality standards. The PO fosters Built-in Quality by writing clear and testable acceptance criteria for backlog items and by being the sole authority to accept completed stories. This ensures that the value delivered is not undermined by technical debt or defects, making it a direct and continuous way the PO supports the team's value delivery process. This responsibility is integral to ensuring the increment is truly 'Done' and valuable.

A. Understanding market forces: This is a critical input for defining what is valuable, but it is more a responsibility of Product Management that the PO collaborates on, rather than a direct support activity for the team during development.
B. Supporting the Architectural Runway: The PO supports the Architectural Runway by prioritizing Enabler stories. However, the primary responsibility for defining and guiding its implementation lies with System Architects/Engineers.
C. Testing benefit hypotheses: This is primarily the responsibility of the Epic Owner and Product Management to validate large-scale initiatives (Epics), not a direct, ongoing support function the PO provides to the Agile team for value delivery.

1. Scaled Agile, Inc. (2023). Product Owner. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/product-owner/. In the section "Supporting the team in delivering value," it states, "Product Owners play a significant role in quality... They are the only team member who can accept stories as done. This includes validating that the story meets its acceptance criteria and has the appropriate, persistent acceptance tests."

2. Scaled Agile, Inc. (2023). Built-In Quality. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/built-in-quality/. This article emphasizes that quality is everyone's responsibility, and the PO's role in defining and accepting work is a crucial part of this practice.

3. Scaled Agile, Inc. (2023). SAFe 6.0 Product Owner/Product Manager (POPM) Course Workbook. This course material details the PO's responsibilities, explicitly linking their role in story acceptance and defining acceptance criteria to the team's ability to deliver value and maintain quality. (Reference to specific lesson on "Executing the Iteration").

A team's velocity is a measure of the amount of work it can complete in an Iteration, expressed in Story Points. To establish a reliable and predictable velocity for future planning, a team calculates the average number of Story Points from Stories that were accepted (met their Definition of Done) in the most recent Iterations. This historical average provides a fact-based measure of the team's capacity, helping them to realistically forecast how much work they can pull into the next Iteration. A single Iteration's result is not as reliable as an average over several.

A. This calculation measures a team's predictability or reliability (e.g., a say-do ratio), not its velocity, which is a measure of throughput.
B. Agile teams complete Stories within an Iteration. Features are larger constructs that typically span multiple Iterations and are completed by the Agile Release Train (ART), not a single team in one Iteration.
D. This represents the team's plan or commitment at the start of an Iteration. Velocity is calculated based on the work that is actually completed and accepted by the end of the Iteration.

1. Scaled Agile, Inc. (2023). Metrics. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/metrics/

Reference Point: In the "Velocity and Load" section, the official documentation states, "Velocity is the number of story points completed in an iteration... For predictability, teams should use their average velocity for the most recent iterations."

2. Scaled Agile, Inc. (2023). Iteration Planning. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/iteration-planning/

Reference Point: Under the "Establishing Capacity" section, it is noted that, "The team’s velocity from the previous Iterations is the primary input for this process." This confirms that historical, completed work is the basis for establishing velocity.

The ART Planning Board is a crucial artifact created and used during the PI Planning event. Its primary purpose is to provide a visual representation of the plan for the upcoming Program Increment. It highlights the sequence of feature delivery, dependencies among the different Agile teams on the Agile Release Train (ART), and any relevant milestones. This visualization is essential for teams to identify and negotiate dependencies, align on the plan, and ensure a shared understanding of the work to be accomplished.

A. ART PI Kanban Board: This board is used to visualize and manage the flow of Features from the backlog through implementation, not for creating the detailed, iteration-by-iteration plan during the PI Planning event.
C. ART PI Risks: This is a list or register of identified risks that are addressed during PI Planning (using the ROAM technique). It visualizes potential problems, not the planned work itself.
D. ART PI Objectives: These are written statements that summarize the business and technical goals a team or train intends to achieve. They represent the value and outcome of the work, not the visual plan of the work and its dependencies.

1. Scaled Agile, Inc. (2023). PI Planning. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/pi-planning/. In the section "Outputs of PI Planning," the article states, "The ART planning board, which highlights the new feature delivery dates, feature dependencies among teams, and relevant Milestones." The article also features multiple images of the board being used during the event.

2. Scaled Agile, Inc. (2023). ART Flow. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/art-flow/. This article describes the ART Kanban as the tool to manage the flow of work (Features) but distinguishes it from the ART Planning Board used specifically within the PI Planning event to map out the plan.

Iteration Goals are a high-level summary of the business and technical goals that an Agile Team agrees to accomplish in an Iteration. Their primary purpose is to align the team members, the Product Owner, and other stakeholders on a common mission for the upcoming Iteration. By defining and communicating a shared purpose, these goals ensure that everyone understands the value and intent behind the selected backlog items, which facilitates better decision-making and collaboration throughout the Iteration. This alignment is crucial for the team to self-organize and deliver a cohesive increment of value.

A. This describes PI Objectives, which are a summary of the business and technical goals an Agile Release Train (ART) intends to achieve in the upcoming Program Increment (PI).
B. Iteration Goals provide flexibility. If an issue arises, the team can adjust which Stories they complete while still striving to achieve the overarching goal for the Iteration.
D. Accountability for PI Objectives is determined at the end of the Program Increment during the Inspect and Adapt event, where business value achieved is scored against the stated PI Objectives.

1. Scaled Agile, Inc. (2023). "Iteration Goals." Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/iteration-goals/. In the "Details" section, the first benefit listed is: "Align team members to a common purpose."

2. Scaled Agile, Inc. (2023). "Iteration Planning." Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/iteration-planning/. The article states, "The PO and the team agree on a set of iteration goals that align with the PI objectives." This highlights the collaborative alignment aspect.

3. Scaled Agile, Inc. (2023). "PI Objectives." Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/pi-objectives/. This article clarifies that PI Objectives summarize the goals for the entire PI, distinguishing them from the shorter-term focus of Iteration Goals.

To ensure a System Demo is effective, teams on the Agile Release Train (ART) must plan for it. By considering what will be demonstrated and how during Iteration Planning, teams can ensure that their work is not only completed but also integrated and ready to be shown as part of a cohesive solution increment. This proactive approach prevents last-minute integration issues and aligns the team's efforts towards a shared, demonstrable goal for the iteration. It shifts the focus from completing individual stories to delivering an integrated piece of value that can be evaluated by stakeholders, which is the primary purpose of the System Demo.

A. Spend a lot of time preparing for the demo: This is a SAFe anti-pattern. Excessive preparation can lead to a scripted presentation rather than a demo of the actual, working system, hiding real issues and reducing transparency.
B. Limit team attendance to minimize disruptions to the team: This is a SAFe anti-pattern. The System Demo is a crucial feedback event for the entire ART; limiting attendance prevents team members from hearing direct feedback and celebrating collective progress.
C. Focus on team-level Metrics: The purpose of the System Demo is to demonstrate the working, integrated solution to get feedback from stakeholders, not to review performance metrics.

1. Scaled Agile, Inc. (2023). System Demo. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/system-demo/.

Supporting Evidence: The article lists "A lot of time is spent preparing for the demo" and "The demo is not attended by the key stakeholders or the teams" as common anti-patterns, directly invalidating options A and B. The event's focus is described as demonstrating the "fully integrated work," which supports the need for planning (Option D).

2. Scaled Agile, Inc. (2023). Iteration Planning. Scaled Agile Framework. Retrieved from https://www.scaledagileframework.com/iteration-planning/.

Supporting Evidence: The article states that during Iteration Planning, teams determine "how much of the team’s backlog they can commit to delivering." This commitment includes ensuring the work is demonstrable in the System Demo, thus linking the planning event directly to the effectiveness of the demo.

3. Scaled Agile, Inc. (2023). SAFe Product Owner/Product Manager Courseware (Version 6.0).

Supporting Evidence: The course materials emphasize that the System Demo is a "forcing function" for integration. To meet this function effectively, teams must plan the integration and demonstration work as part of their Iteration Plan. This directly supports the idea that considering the demo during planning increases its effectiveness.