SAFe Product Owner/Producer Manager POPM 6.0 Exam Notes

Lesson 1: Product Owner/Product Management Roles and Responsibilities

What are the Lean Thinking Principles?

Lean Thinking is to deliver the maximum value (a solution) to the customer in the shortest sustainable lead time from the trigger (the identification of the need or opportunity) to the point at which the customer receives the value. The five principles of Lean thinking are:-

1. Precisely specify value by product
2. Identify the Value Stream for each product
3. Make value flow without interruptions
4. Let the Customer pull value from the producer
5. Pursue perfection

Reference: https://scaledagileframework.com/lean-agile-mindset/

What are the Agile Values?

Agile Manifesto uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
  That is, while there is a value in the items on the right, we value the items on the left more

Lean Thinking and Agile Values are two core building blocks of SAFe.

Reference: https://scaledagileframework.com/lean-agile-mindset/
Reference: https://agilemanifesto.org/

What are the 12 Agile Manifesto Principles?

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for a shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Reference: https://scaledagileframework.com/lean-agile-mindset/
Reference: https://agilemanifesto.org/principles.html

What are the 10 SAFe Lean-Agile Principles?

1. Take an economic view
   1. Deliver Early and Often
   2. Apply a Comprehensive Economic Framework:-
      -Operate Within Lean Budgets and Guardrails
      -Understand Solution Economic Trade-Offs: Development expense, Lead time, Product cost, Value, and Risk
      -Leverage Suppliers
      -Sequencing Jobs for Maximum Benefit: Weighted Shortest Job First (MSJF)
2. Apply systems thinking
   1. The Solution Is a System
      -Optimizing a component does not optimize the whole system
      -For the system to behave well, teams must understand the intended behavior and architecture
      -The value of a system passes through its interconnections
      -A system can evolve no faster than its slowest integration point
   2. The Enterprise Building the System Is a System, Too
   3. Understand and Optimize the Full Development Value Stream
   4. Only Management Can Change the System
3. Assume variability; preserve options
   -Flexible requirements and design, the Cone of uncertainty, set-based over point-based approach
4. Build incrementally with fast, integrated learning cycles
   -PDCA = Plan – Do – Check – Adjust, The shorted the cycles, the faster the learning
   -Integration points control product development and reduce risk
5. Base milestones on objective evaluation of working systems
   -Phase-gate milestones force design decisions too early, false-positive feasibility, they assume a point Solution exists, huge batches and long queues, centralized requirements and design.
   -Use Objective milestones instead, PI System Demos, continuous, cost-effective adjustments towards an optimum Solution
6. Make value flow without interruptions
   -Reduce batch size for higher predictability. Total cost = Holding cost + Transaction cost. Reducing transaction costs increases predictability, accelerates feedback, reduces rework, and lowers cost.
   -Little’s Law: Wq = Lq / Lambda, Average wait time = Average queue length / Average processing rate
7. Apply cadence, synchronize with cross-domain planning
   Cadence – converts unpredictable events into predictable occurrences and lowers cost, makes waiting times for new work predictable, supports regular planning and cross-functional coordination, limits batch sizes to a single interval, controls the injection of new work, provides scheduled integration points;
   Synchronization – causes multiple events to happen simultaneously, facilitates cross-functional trade-offs, provides routine dependency management, supports full system integration and assessment, provides multiple feedback perspectives
8. Unlock the intrinsic motivation of knowledge workers
   -Workers are most qualified to make decisions about how to perform their work
   -The workers must be heard and respected for management to lead effectively
   -Knowledge workers must manage themselves. They need autonomy
   -Continuing innovation must be part of the work, the tasks, and the responsibilities of knowledge workers.
   -Unlocking intrinsic motivation with autonomy, mastery, and purpose
9. Decentralize decision-making
   Centralize – Infrequent, Long-lasting, Significant economies of scale
   Decentralize – Frequent, Time critical, Requires local information
10. Organize around value
    -Value doesn’t follow silos
    -Organize around Development Value Streams.

Reference: https://scaledagileframework.com/safe-lean-agile-principles/

What are the four SAFe core values?

SAFe has the following four core values:-

1. Alignment
2. Transparency
3. Respect for people
4. Relentless improvement

Reference: https://scaledagileframework.com/safe-core-values/

What is Value Streams?

Value streams are the most fundamental construct of Lean thinking and are foundational to SAFe. There are two types of value streams described in SAFe:-

1. Development Value Streams (DVS) is the sequence of activities needed to convert a business hypothesis into a digitally-enabled product or service that delivers customer value.
   — Example of DVS: designing and developing a medical device, developing and deploying a CRM system, or building an e-commerce website.
   — Systems and software developers, product managers, engineers, scientists, and IT practitioners work primarily in the DVS.
   — DVS structure contains: Trigger, Steps, Bar, and Elipses (…)
2. Operational Value Streams (OVS) is the sequence of activities needed to deliver a product or service to a customer.
   — Example: manufacturing a product, fulfilling an e-commerce order, admitting and treating a patient, providing a loan, or delivering a professional service.
   — Common OVS Patterns are Fulfillment, Manufacturing, Software products, and Supporting.
   — OVS flow contains: Steps, People, System, and information & material

DVS develops and supports the product and services used by OVS.

Reference: https://scaledagileframework.com/development-value-streams/
Reference: https://scaledagileframework.com/operational-value-streams/

What is an Agile team?

• An Agile Team is a cross-functional group of typically ten or fewer individuals with all the skills necessary to define, build, test, and deploy increments of value to their customers.
• Agile teams are optimized for communication and the continuous delivery of value to the customer.
• Agile Teams visualize flow with SAFe Scrum or SAFe Kanban
• Agile Team Events are:- Team Sync, Backlog Refinement, Iteration Review, Iteration Retro, Iteration Planning

The Agile Team’s responsibilities are:-

1. Connecting with the Customer (led by PO)
2. Planning the Work: ART Planning (PI Planning), Team planning using SAFe Scrum or SAFe Team Kanban, and refining the Team Backlog.
3. Delivering Value: Frequently integrate and test, Sync with other teams in ART through ART Sync (includes Coach Sync and PO Sync), build continuous delivery pipeline, release frequently.
4. Getting Feedback: with the help of PO and through System Demos
5. Improving relentlessly: participate in ART’s joint Inspect & Adapt, address the problems as they occur

Reference: https://scaledagileframework.com/agile-teams/

What are the two specialty roles in Agile Teams?

The Agile Team contains two specialty roles:- Product Owner (PO) and Scrum Master/Team Coach (SM/TC).

1. Product Owner (PO) responsibilities are:-
   • Connect with the customer
   • Contribute to the Vision and Roadmap
   • Manage and prioritize the Team Backlog
   • Support the team in delivering value
   • Get and apply fast feedback
2. Scrum Master/Team Coach (SM/TC) responsibilities are:-
   • Facilitate SAFe Scrum (or SAFe Kanban) and PI planning
   • Supports Iteration Execution
   • Improves Flow
   • Build a high-performing team
   • Optimizes and improves the team and ART performance

Reference: https://scaledagileframework.com/agile-teams/

What is Agile Release Train (ART)?

• ART is a team of cross-functional Agile Teams and has the capabilities to define, build, validate, and release to deliver a continuous flow of value.
• ART is a virtual organization of 5-12 teams (50-125+ individuals)
• All the teams in ART are synchronized on a common cadence - a Program Increment (PI), aligned to a common mission via a single Program Backlog (ART Backlog).

Critical Roles in the ART are:-

• Release Train Engineer (RTE) is a servant leader (chief scrum master and coach) who facilitates ART execution, impediment removal, risk and dependency management, and continuous improvement.
• Product Management is largely responsible for ‘what gets built,’ as defined by the Vision, Roadmap, and new Features in the ART Backlog. They work with customers, teams, and Product Owners to understand and communicate their needs and participate in solution validation.
• System Architect is an individual or team that defines the system’s overall architecture. They work at a level of abstraction above the teams and components and typically define Non-functional Requirements (NFRs), major system elements, subsystems, and interfaces.
• Business Owners are key stakeholders of the ART, with final responsibility for the business outcomes of the train.
• Customers are the ultimate economic buyers or value users of the solution.

Other essential roles in the ART are:-

• System Teams typically assist in building and maintaining development, continuous integration, and test environments.
• Shared Services are specialists necessary for the success of an ART but cannot be dedicated to a specific train. They often include data security, information architects, site reliability engineering (SRE), database administrators (DBAs), and many more.

Three Sync events to keep ART on track:-

• Coach Sync: (timeboxed: 1 hour) focuses on executing the current PI, including risk, dependencies, progress, and impediments
• PO Sync: manages the PI’s scope, reviews progress, adjusts priorities, and prepares for the following PI
• ART Sync: usually replaces the Coach Sync and PO Sync for a particular iteration to reduce overhead. The ROAM board created during PI planning can be reviewed during the ART Sync. ART Planning board is used during ART sync to track and manage dependencies, ensuring they do not block other teams.

Other events in ART:-

• PI Planning (timeboxed: 2 days) Each ART begins with the PI Planning using the PI planning board, the outcome is PI Objectives to be completed in the PI iteration.
• System Demos (timeboxed: 1 hour) Occur at the end of Iteration to review deliverables and receive feedback from stakeholders, business owners, and customers.
• Inspect & Adapt (timeboxed: 1/2 day) Each PI concludes with I&A event for retrospection where ART reviews and improves its process before the next PI.

Reference: https://scaledagileframework.com/agile-release-train/
Reference: https://scaledagileframework.com/planning-interval/

What are the responsibilities of the Product Owner?

Product Owner (PO) is the team’s primary customer advocate and primary link to business and technology strategy. They have the following responsibilities:-

1. Connecting with the Customer
2. Contributing to the Vision and Roadmap
3. Managing and Prioritizing the Team Backlog
4. Supporting the Team in Delivering Value
5. Getting and Applying Feedback

Reference: https://scaledagileframework.com/product-owner/

What are the responsibilities of Product Management?

Product Management has the following responsibilities:-

1. Exploring Markets and Users
2. Connecting with the Customer
3. Defining Product Strategy, Vision, and Roadmaps
4. Managing and Prioritizing the ART Backlog
5. Delivering Value

Reference: https://scaledagileframework.com/product-management/

What are the content authorities of the Product Owner?

• Has Team Backlog content authority
• Works with the System Architect to prioritize Enablers
• Guides Iteration Goals and content via prioritized Stories
• Establish Story acceptance criteria
• Has authority for accepting Stories and team increments
• Helps guide PI Objectives at the team level

Reference: https://scaledagileframework.com/product-owner/

What are the content authorities of Product Management?

• Has ART Backlog content authority
• Works with the System Architect and team to prioritize Enablers
• Has content authority for Vision and Roadmap
• Helps guide PI Objectives
• Establish Features and acceptance criteria

Reference: https://scaledagileframework.com/product-management/

Lesson 2 - Preparing for PI Planning

What is Planning Interval (PI)?

• A Planning Interval (PI) is a cadence-based timebox in which Agile Release Trains deliver continuous value to customers in alignment with PI Objectives.
• PIs are typically 8 – 12 weeks long. The most common pattern for a PI is four development Iterations, followed by one Innovation and Planning (IP) Iteration.

Reference: https://scaledagileframework.com/planning-interval/

What is PI Planning and its events?

• PI Planning stands for Program Increment Planning.
• PI Planning is a cadence-based event that serves as the heartbeat of the ART, aligning all teams on the ART to a shared mission and Vision.
• PI Planning sessions are regularly scheduled events held throughout the year where multiple teams within the same Agile Release Train (ART) meet to align to a shared vision, discuss features, plan the roadmap, and identify cross-team dependencies.
• PI Planning is a 2 full day event that typically runs every 8-12 weeks (10 weeks typical). The two-day agenda is as follows:-

  Day 1
  08:00 - 09:00	Business Context
  09:00 - 10:30	Product/Solution Vision
  10:30 - 11:30	Architecture Vision and Development Practices
  11:30 - 01:00	Planning Context and Lunch
  01:00 - 04:00	Team breakouts
  04:00 - 05:00	Draft Plan Review
  05:00 - 06:00	Management review and problem solving

  Day 2
  08:00 - 09:00	Planning Adjustment
  09:00 - 11:00	Team breakouts
  11:00 - 01:00	Final Plan Review and Lunch
  01:00 - 02:00	ART Risks
  02:00 - 02:15	Confidence Vote
  02:15 - ??	Plan Rework (if needed)
  When ready	Planning Retrospective and moving forward

• Primary Inputs to the PI Planning include: 1. Business context, 2. Roadmap & vision, and 3. Highest priority Features (typically top 10) of the ART backlog
• Primary Outputs of the PI Planning include: 1. Committed PI objectives, and 2. ART planning board
• Product Management provides the vision and backlog (typically represented by the top ten or so upcoming features) and owns the feature priorities
• Business Owner provides the business context and assigns a business value (BV) to each PI Objective on a scale from 1 to 10
• Development Teams own Story planning and high-level estimates
• ART Planning Board is used for PI Planning showing: 1. Features, 2. Significant Dependency, and 3. Milestone or Event
• Architects and UX work as intermediaries for governance, interfaces, and dependencies

Reference: https://scaledagileframework.com/pi-planning/

What are PI’s Uncommitted Objectives?

Uncommitted objectives are used to identify work that can be variable within the scope of a PI. The work is planned, but the outcome is simply not certain. Teams can apply uncommitted objectives whenever there is low confidence in meeting the objective. This can be due to many circumstances:

• Dependencies with another team or supplier that cannot be guaranteed.
• The team has little to no experience with functionality of this type. In this case the teams may plan ‘Spikes’ early in the PI to reduce uncertainty.
• There are a large number of fairly critical objectives that the business is depending on and the team is already loaded close to full capacity.

Reference: https://scaledagileframework.com/pi-planning/

What is a Feature?

• Features are maintained in the ART Backlog
• Feature are sized to fit in a Program Increment (PI) and delivered by a single Agile Release Train (ART)
• Features are split into Stories and fit in one Iteration for one team
• Features include a definition of Minimum Marketable Feature (MMF), a benefit hypothesis (to justify development cost) and Acceptance criteria (defined during program backlog refinement).
• Features are prioritized using WSJF and the top 10 features are presented to the team during PI planning
• Typically Product Management creates business features and System Architect creates enabler features

Reference: https://scaledagileframework.com/features-and-capabilities/

Lesson 3: Leading PI Planning

What do the Product Owner and Product Management do on day 1 of PI Planning?

• Communicate the Vision
  — Present to the ART how the vision aligns with Strategic Themes and Solution Context
  — Prepare material and provide user personas to illustrate and explain the Vision
  — Explain the importance of NFR
• Communicate the Roadmap
  — Show how PI roadmaps in this PI help fulfill the vision
  — Describe how PI roadmaps support Key Epics and Milestones
• Communicate the top 10 features to the ART
  — Discuss and refine features through backlog refinement before PI Planning
  — Prepare to explain why these features were chosen
  — Top 10 features is a guideline. ART may pull more or less.
• Collaborate to decompose Features into Stories
• Negotiate Scope
• Review draft PI plans and provide feedback
• Participate in management review of draft plans

What do the Product Owner and Product Management do on day 2 of PI Planning?

• Support team breakouts
• Accept team PI Objectives
• Establish business value with Business Owners
• Participate in the final plan review
• Provide feedback on ART PI Risks
• Participate in the confidence vote

Lesson 4: Executing Iterations

What is a Feature?

• Features are maintained in the ART Backlog
• Feature are sized to fit in a Program Increment (PI) and delivered by a single Agile Release Train (ART)
• Features are split into Stories and fit in one Iteration for one team
• Features include a definition of Minimum Marketable Feature (MMF), a benefit hypothesis (to justify development cost) and Acceptance criteria (defined during program backlog refinement).
• Features are prioritized using WSJF and the top 10 features are presented to the team during PI planning
• Typically Product Management creates business features and System Architect creates enabler features

Reference: https://scaledagileframework.com/features-and-capabilities/

What is a Story?

• Features are implemented by Stories
• Stories are small increments of value that can be developed in days and are relatively easy to estimate
• Stories are created during PI planning as the team collaborates with POs and Product Management
• Features fit in one PI for one ART; Stories fit in one iteration for one team.
• A Story Point is a relative number that represents: Volume, Complexity, Knowledge, and Uncertaity.
• Team breaks down Features into one or more User Stories and Enabler Stories
• User Stories expressed desired end-user functionality written in the user’s language
• Enabled Stories support exploration, architecture, infrastructure, and compliance

Reference: https://scaledagileframework.com/story/

When is a Story complete?

A Story is complete when it satisfies the definition of done (DoD). The DoD requires that the story:-
— Satisfies the acceptance criteria
— Is accepted by the Product Owner

Lesson 5: Executing the PI

What is PO Sync?

• Provides visibility into how well the ART is progressing toward meeting the ART PI Objectives
• Provides an opportunity to access scope and priority adjustments
• Is facilitated by RTE or Product Management
• Includes Product Managers, POs, Stakeholders, and SMEs, as necessary
• Occurs weekly or more frequently and lasts 30-60 minutes long

POs communicate the adjustments to their team after the PO Sync

Reference: https://scaledagileframework.com/planning-interval/

What is Inspect and Adapt (I&A) Event?

• The Inspect and Adapt (I&A) is a significant event (Timebox: 3-4 hours) held at the end of each PI, where All ART stakeholders and the Agile Team participate.
• The I&A event consists of three parts:-
  – PI System Demo (Timebox: 45-40 mins) - team demonstrates the current state of the solution
  – Quantitative and qualitative measurement - Team PI performance report is created which includes team’s planned vs actual business value. Individual team totals are rolled up into the ART predictability report.
  – Retrospective and problem-solving workshop

Reference: https://scaledagileframework.com/inspect-and-adapt/

What is a PI System Demo?

• The PI System Demo is the event (Timebod: 1 hour) held at the end of each PI, to demonstrate the current state of the solution to appropriate stakeholders
• Often led by Product Management, Product Owners, and the System Team
• Attended by Business Owners, ART Stakeholders, Product Management, RTE, Scrum Masters/Team Coaches, and teams.

Reference: https://scaledagileframework.com/system-demo/

What is Innovation and Planning (IP) Iteration?

• The Innovation and Planning (IP) Iteration is a unique iteration that occurs every PI, which provides dedicated time for Innovation and Planning where:-
  –– Innovation includes opportunities for innovation, hackathons, infrastructure improvements, continuing education, certifications, etc.
  –– Planning includes PI Planning Readiness, Inspect and Adapt (I&A), and PI Planning events, etc.
• It provides:- — an estimating buffer for meeting PI Objectives
  — an estimating guard band for cadence-based delivery
  — sufficient capacity margin to enable cadence
• Without the IP Iteration
  – Lack of delivery capacity buffer impacts predictability
  – Little innovation; the tyranny of the urgent
  – Technical debt grows uncontrollably
  – People burn out
  – No time for teams to plan, demo, or improve together

Reference: https://scaledagileframework.com/innovation-and-planning-iteration/