SAFe-Practitioner SAFe Practitioner Exam (6.0) Questions and Answers

Resizing the work is one method for reducing queue length in SAFe. Queue length is the number of work items waiting to be processed in a system. Reducing queue length can improve flow, reduce cycle time, and increase throughput. Resizing the work means breaking down large work items into smaller ones that can be completed faster and with less variability. Smaller work items also reduce the risk of rework, defects, and delays. Resizing the work can be done at any level of SAFe, from portfolio epics to team stories. SAFe provides several techniques for resizing the work, such as Weighted Shortest Job First (WSJF), Minimum Marketable Features (MMFs), Minimum Viable Products (MVPs), and Spikes1. References: Principle #6 - Visualize and Limit WIP, Reduce Batch Sizes, and Manage Queue Lengths - Scaled Agile Framework

Conducting a PI Planning event is an example of applying cadence-based synchronization in SAFe. A PI Planning event is a two-day face-to-face or virtual meeting where all the members of an ART and Solution Train collaborate to align on a common vision, mission, and backlog, and plan the work for the next Program Increment (PI). A PI is a fixed timebox of 8 to 12 weeks that provides a regular cadence for delivering value. The PI Planning event is synchronized across all the teams and trains in the portfolio, and it occurs at the beginning of every PI. The PI Planning event enables the ART and Solution Train to achieve alignment, collaboration, synchronization, and commitment, as well as to identify and address risks and dependencies. References: = PI Planning - Scaled Agile Framework, Exam Study Guide: SP (6.0) - SAFe® Practitioner

Iteration planning for Kanban teams is different from Scrum teams in that Kanban teams do not estimate their velocity, do not commit to service level agreements, and do not plan the Iteration in detail. Instead, Kanban teams use a flow-based process that allows them to pull work items from the backlog as they become available and deliver value continuously. However, Kanban teams still operate within the ART iteration cadence and often publish Iteration goals to align with the ART vision and objectives, as well as to communicate their priorities and dependencies to other teams and stakeholders. References: SAFe Team Kanban, Agile Iteration Planning Effectively

 The Agile Release Train Sync is a weekly meeting that synchronizes the ART stakeholders and provides visibility into the ART’s progress and impediments1. The Scrum Masters represent their Agile teams, provide updates on their status, relay questions, and help address challenges. They safeguard the team’s needs and effectiveness2. The visibility that Scrum Masters provide during the Agile Release Train Sync is mainly into the progress and impediments of their teams, such as the completion of features, stories, and enablers, the resolution of dependencies, the identification of risks and issues, and the demonstration of value3. The other options are not the primary focus of the Scrum Masters’ visibility during the Agile Release Train Sync. References: Agile Release Train - Scaled Agile Framework, PRACTICE TEST: SAFe 4 Practitioner Certification Flashcards - Brainscape, Agile Release Train Sync Meetings: Maximizing Success - Dee Project Manager

The role of the System Architect/Engineer in SAFe is to guide the teams and support the Architectural Runway, which is the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay. The System Architect/Engineer defines and communicates the technical and architectural vision for the solutions developed by an Agile Release Train (ART), ensuring that they fit the intended purpose and align with the enterprise and solution architecture. The System Architect/Engineer also collaborates with various roles, teams, and stakeholders within and outside the ART to ensure that the system architecture supports the evolving business needs and enables fast and reliable implementation. References: System Architect/Engineering - Scaled Agile Framework, Architectural Runway - Scaled Agile Framework

 A cross-functional Agile Team is a team that has all the skills and competencies needed to define, build, and test an increment of value in an Iteration. A cross-functional Agile Team is composed of team members who have different roles and expertise, such as developers, testers, analysts, designers, etc. A cross-functional Agile Team is also optimized for communication and delivery of value, as it minimizes the handoffs, dependencies, and delays that may occur when working with other teams or functions. A cross-functional Agile Team is able to collaborate effectively, deliver value frequently, and respond to changing customer needs and feedback. References: Exam Study Guide: SP (6.0) - SAFe® Practitioner, Agile Team

user business value and time criticality are components of Cost of Delay (CoD), which is a measure of the economic value of a job over time. CoD is used to prioritize jobs based on the Weighted Shortest Job First (WSJF) model, which is part of the SAFe methodology. CoD is calculated as the sum of three components: user/business value, time criticality, and risk reduction and/or opportunity enablement. User/business value indicates the relative importance and revenue impact of a job. Time criticality indicates the urgency and value decay of a job. Risk reduction and/or opportunity enablement indicates the long-term benefits of a job12. References: 1: WSJF - Scaled Agile Framework2: WSJF = (Biz Value + Time Crit. + Risk Reduce) / Job Size

The purpose of building a continuous delivery pipeline is to enable a streamlined and automated process of delivering software value to the end users. A continuous delivery pipeline consists of four aspects: continuous exploration, continuous integration, continuous deployment, and release on demand. These aspects work together to support the delivery of small batches of new functionality, which are then released to fulfill market demand. Building and maintaining a continuous delivery pipeline allows each Agile Release Train (ART) to deliver new functionality to users far more frequently than with traditional processes, which often involve long and complex release cycles. By delivering value more frequently, the ART can respond faster to customer feedback, reduce waste, improve quality, and increase business agility. References: Continuous Delivery Pipeline - Scaled Agile Framework, Continuous Delivery Pipeline - Scaled Agile Framework, SAFe Continuous Delivery Pipeline: A Comprehensive Guide to the …, Continuous Delivery Pipeline: The 5 Stages Explained - Codefresh

Iteration Planning is a key event in the SAFe framework that occurs at the beginning of each Iteration. It is a timeboxed meeting where the Agile team collaborates to plan the work for the upcoming Iteration, based on the team backlog, the Iteration goal, and the team capacity. Iteration Planning enables fast learning cycles by allowing the team to inspect and adapt their work frequently, deliver value incrementally, and respond to changing customer needs and feedback. References: Exam Study Guide: SP (6.0) - SAFe® Practitioner, Planning the Iteration, Executing the Iteration

n: A backlog refinement session is a periodic activity teams use to define, discuss, estimate, and establish acceptance criteria for upcoming backlog items1. One key benefit of a backlog refinement session is that it provides time to identify dependencies and issues that could impact the next iteration. By doing so, teams can reduce uncertainty, avoid surprises, and plan more effectively. Backlog refinement also helps surface problems with the current plan, which may require discussion at the team, PO, or coach syncs2. Additionally, backlog refinement helps teams align their backlog with the ART backlog, the PI objectives, and the customer needs2. References: Backlog Refinement - Scaled Agile Framework, Team Backlog - Scaled Agile Framework

One benefit of Story acceptance criteria is to provide Story details from a testing point of view. Acceptance criteria are the conditions or rules that a user story must meet to be considered complete and acceptable by the customer or stakeholder. They define the scope and boundaries of the user story and help the team to understand what needs to be done and how to test it. Acceptance criteria also facilitate communication and collaboration between the team and the customer or stakeholder, as they provide a common language and a shared understanding of the expected outcome. References: What is User Story and Acceptance Criteria (Examples), Acceptance Criteria: Everything You Need to Know Plus Examples

The three levels of the Scaled Agile Framework are Essential, Large Solution, and Portfolio. These levels represent the different levels of abstraction and complexity involved in delivering value to customers. The Essential level is the foundation of SAFe and includes the Team and Program levels, where agile teams and agile release trains (ARTs) work together to deliver solutions. The Large Solution level is an optional level that supports the coordination and alignment of multiple ARTs and suppliers that build large and complex solutions that require additional roles, events, and artifacts. The Portfolio level is the highest level of SAFe and provides strategic direction, funding, governance, and value stream management for the entire portfolio of solutions. References: SAFe® for Teams - Know Your Role on an Agile Team, Exam Study Guide: SP (6.0) - SAFe® Practitioner, SAFe 5.0 Framework

The Product Owner role is the Agile team member primarily responsible for maximizing the value delivered by the team by ensuring that the team backlog is aligned with customer and stakeholder needs1. As a member of the extended Product Management function, the Product Owner is the team’s primary customer advocate and primary link to business and technology strategy1. This means that the Product Owner represents the customer to the Agile team, and communicates the product vision, goals, and requirements to the team. The Product Owner also collaborates with the customer and other stakeholders to gather feedback, validate assumptions, and ensure that the team is building the right things and building them right23. References: = 1: Product Owner - Scaled Agile Framework1; 2: What is a Product Owner? | Scrum.org2; 3: I’m a New Product Owner! What Are My Responsibilities? - Scrum Alliance3

= As a Product Owner, James is responsible for managing the Iteration backlog and ensuring that the most valuable and feasible work items are delivered by the team1. If the team tells him that they may miss their Iteration commitment, James should collaborate with them to review and reprioritize the backlog, and identify the minimum viable increment that can be completed within the Iteration timebox2. James should not support adding an Innovation and Planning Iteration, as this would disrupt the cadence and synchronization of the Agile Release Train3. James should not agree to add a person from the System Team, as this would violate the team autonomy and self-organization principles4. James should not support splitting a Story into a coding story and a testing story, as this would create technical debt and compromise the quality and value of the deliverable5. References: = 1: Product Owner - Scaled Agile Framework6; 2: Iteration Planning - Scaled Agile Framework7; 3: Innovation and Planning Iteration - Scaled Agile Framework8; 4: Agile Teams - Scaled Agile Framework9; 5: Story - Scaled Agile Framework10

SAFe provides a second operating system that enables Business Agility by creating a network of Agile teams and trains that are aligned to a common vision and strategy, and empowered to deliver value to customers and users. SAFe leverages the Lean-Agile mindset, the core competencies, and the principles and practices to foster a culture of innovation, learning, and collaboration. SAFe also supports the continuous delivery pipeline, which enables fast feedback and frequent value delivery. References: SAFe® for Teams - Know Your Role on an Agile Team | Scaled Agile, Exam Study Guide: SP (6.0) - SAFe® Practitioner - scaledagile.com, SAFe 6.0 for Teams with SP Certification - ICON Agility Serviceswq

A component team is an Agile Team whose primary area of concern is focused on a specific component, or set of components, of the system. They leverage their technical skills and interest and focus on building robust components that provide for reliability, separation of concerns, foster re-use, and improve testability. Component teams are typically used when the system has complex, nonfunctional requirements that require deep technical expertise and specialization, such as performance, security, scalability, etc. Component teams can also enable high reuse of components across multiple solutions, reducing duplication and waste. However, component teams also introduce challenges, such as increased dependencies, coordination, and integration efforts with other teams, as well as reduced end-to-end value delivery and customer feedback. Therefore, component teams should be used sparingly and only when the benefits outweigh the costs. References: Organizing Agile Teams and ARTs: Team Topologies at Scale, Agile Teams, Feature Teams vs Component Teams, System Team, Feature Team vs Component Team in Agile

Lean Thinking is a philosophy that aims to create value for customers by eliminating waste and unnecessary steps in company processes. One of the main sources of waste is delay, which can be caused by long lead times, large batch sizes, excessive inventory, poor quality, and lack of coordination. Reducing delays can improve customer satisfaction, increase efficiency, and lower costs. Lean Thinking is based on two pillars: respect for people and continuous improvement. Respect for people means empowering and engaging employees, customers, and stakeholders to participate in problem-solving and innovation. Continuous improvement means constantly seeking ways to improve the process and the product by applying the Plan-Do-Check-Act cycle and the scientific method. References: Lean-Agile Mindset - Scaled Agile Framework, Lean Thinking: Overview, Principles, Benefits, & Applications Explained, The Focus of Lean - Collin College, What is Lean? - Project Management Institute

Respect for People is one of the four SAFe Core Values that guide the behaviors and actions of everyone participating in a SAFe portfolio. Respect for People means that everyone is valued and deserves respect, regardless of their role, background, or experience. It also means that everyone is empowered to contribute, learn, and grow within the organization. Respect for People involves coaching aspiring developers to grow their skillsets and fill new roles throughout the organization, as well as providing them with opportunities for feedback, recognition, and career development. Respect for People also fosters a culture of trust, collaboration, and psychological safety, where people can express their ideas, opinions, and concerns without fear of judgment or retaliation. References: Core Values - Scaled Agile Framework, Respect for People - Scaled Agile Framework

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 not certain. Teams can apply uncommitted objectives whenever there is low confidence in meeting the objective. Uncommitted objectives do not get assigned a business value score because they are not part of the ART predictability measure. They are also not included in the program predictability report. However, they are still important and valuable, and teams should strive to achieve them if possible. References: PI Objectives, PI Planning, What is an uncommitted objective in SAFe?

= The SAFe Lean-Agile principle that involves delivering a continuous flow of value to customers in the shortest sustainable lead time is “Make value flow without interruptions”. This principle is based on the Lean concept of optimizing the whole value stream, from concept to cash, by eliminating delays, queues, handoffs, and rework. By applying practices such as limiting work in progress (WIP), reducing batch sizes, managing queue lengths, and implementing continuous integration and continuous delivery (CI/CD), SAFe teams and trains can accelerate the flow of value and feedback, improve quality and reliability, and reduce waste and overhead. References: = SAFe Lean-Agile Principles - Scaled Agile Framework, Accelerating Flow with SAFe - Scaled Agile Framework1, The Five Principles of Lean - Project Management Institute

The principle that includes “working software is the primary measure of progress” is one of the twelve principles behind the Agile Manifesto. The Agile Manifesto is a declaration of four values and twelve principles that guide the Agile software development movement. The value that corresponds to this principle is “working software over comprehensive documentation”. The principle states that the ultimate goal of any software development project is to deliver working software that satisfies the customer’s needs and expectations, and that any other intermediate or auxiliary artifacts, such as plans, documents, models, or reports, are secondary and should not distract from the main objective. The principle also implies that working software should be delivered frequently and continuously, and that the progress of the project should be measured by the amount and quality of the software delivered, not by the adherence to a predefined plan or schedule. References: Principles behind the Agile Manifesto, Agile Manifesto - Scaled Agile Framework

Velocity is a measure of how much work a team can complete in an iteration. It is based on the team’s historical performance and estimation accuracy. During iteration execution, a team’s velocity tends to be most affected by factors that change the team’s capacity, collaboration, and context. Changing team size, team makeup, and technical context are examples of such factors. For instance, adding or removing team members, changing team roles or responsibilities, or switching to a different technology or domain can all impact the team’s velocity. Therefore, the correct answer is B. Changing team size, team makeup, and technical context. References: Velocity - Scaled Agile Framework, PRACTICE TEST: SAFe 4 Practitioner Certification Flashcards - Brainscape, During Iteration Execution, a team velocity tends to be most affected …

According to the SAFe-for-Teams-SAFe-Practitioner-6-0 documents, a minimum viable product (MVP) is an early and minimal version of a new solution sufficient to prove or disprove an epic hypothesis1. An MVP is not a prototype, a feature, or a product. It is a learning tool that helps validate assumptions, reduce uncertainty, and increase the likelihood of building the right thing2. Therefore, the correct answer is A. A minimal version of a new product used to test a hypothesis. References: Epic - Scaled Agile Framework, What is a Minimum Viable Product (MVP)? | Agile Alliance

 According to the SAFe framework, some decisions are strategic, have far-reaching impact, and are outside the scope, knowledge, or responsibilities of the teams. These decisions should be centralized, as they are made by leaders who have the market knowledge, longer-range perspectives, and understanding of the business and financial landscape necessary to steer the enterprise. One of the characteristics of these types of decisions is that they provide significant economies of scale, meaning that they deliver large and broad economic benefits to the organization. Examples of such decisions are a common way of working, standard development languages, standard tooling, and offshoring. These decisions are infrequent, long-lasting, and require coordination and alignment across multiple teams and value streams. References: Principle #9 - Decentralize Decision-Making - Scaled Agile Framework, SAFe® and Importance of Decentralized Decision Making – Learnow

Lean-Agile leaders try to connect the silos of business, software, test, and quality assurance to create a culture of collaboration and shared responsibility across the value stream. By breaking down the barriers between different functions, Lean-Agile leaders enable faster feedback, shorter lead times, higher quality, and better customer satisfaction. Connecting the silos also helps to align the teams around a common vision, mission, and goals, and to foster a Lean-Agile mindset that embraces change and innovation. References: SAFe Core Values, Agile Practice Exam Flashcards, SAFe 4.6 exam prep - Improved - extended Flashcards, Stop Breaking Down Silos and Start Connecting Them

SAFe Implementation Roadmap is a template for putting SAFe into practice within an organization. It consists of an overview graphic and a 14-article series that describes a strategy and an ordered set of activities for successfully implementing SAFe. The roadmap is based on proven organizational change management strategies and successful adoption patterns from hundreds of the world’s largest enterprises. The roadmap helps leaders and change agents to script the critical moves, create a sense of urgency, build a guiding coalition, form a strategic vision, enlist a volunteer army, enable action by removing barriers, generate short-term wins, sustain acceleration, and institute change. References: Implementation Roadmap - Scaled Agile Framework, SAFe® for Teams - Know Your Role on an Agile Team | Scaled Agile

 Features are used to describe functional and non-functional requirements in SAFe. Features are services that fulfill stakeholder needs and deliver value to the customer. They are typically 10-12 weeks of development effort and can span multiple iterations. Features are derived from the Program Backlog and are prioritized by the Product Management. Features are also used to define the PI Objectives and measure the business value delivered by the Agile Release Train (ART). References: SAFe for Teams Student Workbook: materials and exercises from Lesson 3; v6.scaledagileframework.com/features/

 The Continuous Delivery Pipeline represents the workflow, activities, and automation needed to deliver new functionality more frequently. It consists of four elements: Continuous Exploration, Continuous Integration, Continuous Deployment, and Release on Demand. The pipeline enables faster value delivery, higher quality, and lower risk. References: Exam Study Guide: SP (6.0) - SAFe® Practitioner, Continuous Delivery Pipeline, Lesson 4: Deliver Value

One of the roles of Product Management is to assign business value to Features. Features are services provided by the system that fulfill stakeholder needs. They are the primary artifact for defining, managing, and prioritizing the work of the Agile Release Train (ART). Product Management is responsible for defining and prioritizing the features in the Program Backlog, as well as assigning a business value to each feature based on its expected benefits and costs. The business value is used to guide the economic decision-making and trade-offs during PI Planning and execution. Product Management also collaborates with other roles, such as Solution Management, System Architects, and Business Owners, to ensure that the features align with the solution vision and roadmap, and meet the quality standards and nonfunctional requirements. References: Features - Scaled Agile Framework, Product Management - Scaled Agile Framework

The PI Planning event is a two-day event that brings together all the teams and stakeholders of an Agile Release Train (ART) to align on a common vision, mission, and goals for the upcoming Program Increment (PI). The PI Planning event involves everyone in the program, including the Business Owners, Product Management, System Architects, Agile teams, Scrum Masters, Product Owners, Release Train Engineers, and other relevant roles. The PI Planning event also fosters collaboration, communication, and commitment among the participants, and helps identify and address the risks and impediments that may affect the delivery of value. References: Exam Study Guide: SP (6.0) - SAFe® Practitioner, PI Planning

 An Iteration is a fixed timebox during which an Agile team delivers a potentially releasable increment of value. The recommended length of an Iteration is two weeks, as this allows for fast feedback, adaptation, and learning cycles. Longer Iterations may increase the risk of overcommitment, scope creep, and reduced quality. Shorter Iterations may increase the overhead of planning and coordination, and reduce the amount of value delivered per Iteration. References: Exam Study Guide: SP (6.0) - SAFe® Practitioner, [Iteration]

 Trust is the foundation of any successful collaboration, especially between the business and development teams, who often have different perspectives, expectations, and incentives. Trust exists when everyone can confidently rely on one another to act with integrity, particularly in times of difficulty. Without trust, it is impossible to build high-performing teams and trains or build (or rebuild) the confidence needed to make and meet reasonable commitments1. One way to gain trust between the business and development is to deliver predictability, which means that the teams and the Agile Release Train (ART) can consistently deliver value in the shortest sustainable lead time, with the best quality and value, and meet the agreed-upon objectives and goals2. Predictability is achieved by applying the SAFe principles and practices, such as aligning to a common mission and vision, planning and executing in iterations and increments, applying systems thinking and feedback loops, and embracing change and innovation3. Predictability helps to establish and maintain trust between the business and development, as it demonstrates the reliability, transparency, and accountability of the teams and the ART, and it enables the business to make informed decisions and provide timely feedback4. The other options are not the best ways to gain trust between the business and development, as they either do not address the core issue of trust, or they may have negative consequences. Automating the delivery pipeline is a technical practice that supports DevOps and continuous delivery, and it can improve the speed, quality, and efficiency of the value delivery, but it does not necessarily build trust between the business and development, as it does not address the communication, collaboration, and alignment aspects of trust. Releasing new value to production every day is a desirable outcome of DevOps and continuous delivery, and it can provide fast feedback and validation of the value delivered, but it does not guarantee trust between the business and development, as it may also introduce risks, errors, and instability, and it may not reflect the actual needs and expectations of the customers and stakeholders. Maintaining iterations as a safe zone is a practice that protects the teams from external interference and distractions during the iteration execution, and it can help the teams focus on their work and deliver value, but it does not foster trust between the business and development, as it may also create silos, isolation, and resistance to change, and it may prevent the teams from collaborating and communicating with the business and other teams. References: Core Values - Scaled Agile Framework, Predictability - Scaled Agile Framework, SAFe Lean-Agile Principles - Scaled Agile Framework, How can trust be gained between the business and development?

Systems thinking is a holistic approach to solution development, incorporating all aspects of a system and its environment into the design, development, deployment, and maintenance. It requires leaders and teams to understand the solution, the enterprise, and the value stream as a system. One of the principles of systems thinking is that optimizing a component of the system does not optimize the whole system. In fact, it may even harm the system performance, as it may create bottlenecks, conflicts, or waste in other parts of the system. Therefore, systems thinking encourages looking at the system as a whole and finding the best trade-offs and synergies among the components. References: Principle #2 - Apply systems thinking - Scaled Agile Framework, What ‘systems thinking’ actually means - and why it matters today | World Economic Forum, What is Systems Thinking? - Critical Thinking Secrets

Release Governance is the process that guides the final approval for a release in SAFe. It involves a set of roles and responsibilities that ensure the quality, compliance, and fitness for purpose of the solution before it is released to customers. Release Governance also coordinates the timing and frequency of releases based on market demand and business needs. Release Governance is part of the Release on Demand aspect of the Continuous Delivery Pipeline, which is the fourth and last element in the four-part pipeline of Continuous Exploration, Continuous Integration, Continuous Deployment, and Release on Demand. References: Release on Demand - Scaled Agile Framework, SAFe for teams 93% Flashcards | Quizlet, Release on Demand - SAFe 4.5 Reference Guide: Scaled Agile Framework …

A team’s commitment at the end of PI Planning is based on the PI Objectives that they have defined and negotiated with the Business Owners and other stakeholders. PI Objectives are SMART (Specific, Measurable, Achievable, Relevant, and Time-bound) goals that reflect the expected business and technical outcomes for the upcoming PI. A team does not commit to uncommitted objectives, which are stretch goals that may or may not be achieved depending on the actual capacity and velocity of the team. Uncommitted objectives are not included in the vote of confidence or the business value assessment. References: PI Objectives - Scaled Agile Framework, SAFe® for Teams - Know Your Role on an Agile Team | Scaled Agile, Exam Study Guide: SP (6.0) - SAFe® Practitioner - scaledagile.com

Emergent design and intentional architecture are two complementary approaches to designing and evolving a system’s architecture. Emergent design enables fast, local control so that teams can react appropriately to changing requirements without excessive attempts to future-proof the system. Intentional architecture provides the guidance needed to ensure that the whole system has conceptual integrity and is fit for its purpose. Balancing these two approaches is required for speed of value delivery and Solution Intent, which is the representation of the desired and actual solution behavior, including the functional and nonfunctional aspects. Solution Intent guides the development and evolution of the solution and helps align the teams and stakeholders on the vision and goals of the solution. References: Architectural Runway, Agile Architecture in SAFe, Balancing Emergent Design and Intentional Architecture in Agile Software Development

The Release Train Engineer (RTE) is a servant leader and coach for the Agile Release Train (ART), which is a group of Agile teams that work together to deliver value. The RTE facilitates the ART events and processes, and supports the teams in delivering value. They communicate with stakeholders, escalate impediments, help manage risk, and drive relentless improvement. The RTE also serves as the Scrum Master for the ART, which means they help the teams apply and improve the Scrum practices, such as planning, reviewing, and retrospecting. The RTE is not the technical leader, the content authority, or the program manager of the ART, but rather the facilitator and enabler of the ART’s success. References: Release Train Engineer - Scaled Agile Framework, Release Train Engineer (RTE): Responsibilities and Skills | Indeed.com

 During the team breakout session, each team creates and estimates their Stories, and sequences them into a draft plan for the upcoming PI. This is where the team backlog is refined and prioritized, and dependencies are identified and resolved. References: SAFe for Teams - Know Your Role on an Agile Team, Exam Study Guide: SP (6.0) - SAFe® Practitioner, SAFe for Teams | SAFe Practitioner (SP) Certification

 The balance between emergent design and intentional architecture when building in quality is required for speed of development and maintainability. Emergent design is the practice of defining and evolving the architecture only as necessary to deliver the next increment of functionality, based on the feedback and learning from the previous increments. Intentional architecture is the practice of defining and implementing some upfront design guidelines and standards that enable the integration and evolution of the solution across multiple teams and domains. Both practices are implemented with enablers, which are technical items that support the development and delivery of features and capabilities. The balance between emergent design and intentional architecture allows the teams and the Agile Release Train (ART) to deliver value faster, with higher quality and lower risk, and to maintain and improve the solution over time12. The other options are not accurate descriptions of the balance between emergent design and intentional architecture, as they either do not reflect the benefits of both practices, or use terms that are not relevant to the SAFe context. References: Architectural Runway - Scaled Agile Framework, Built-In Quality - Scaled Agile Framework

The PO’s best course of action is to communicate the status of the Iteration to all stakeholders, including the other teams on the Agile Release Train (ART), the Release Train Engineer (RTE), the System Architect/Engineer, the Product Management, and the Business Owners. This will help to align expectations, manage dependencies, and mitigate risks. The PO should also collaborate with the team and the stakeholders to prioritize the remaining work and identify the most valuable Stories to deliver by the end of the Iteration. The PO should not defer acceptance testing to the next Iteration, as this would violate the Definition of Done and compromise the quality of the system increment. The PO should not have an emergency Iteration Planning meeting, as this would disrupt the cadence and synchronization of the ART and waste time and resources. The PO should not stop the current Iteration and plan a new Iteration with the new knowledge, as this would also disrupt the cadence and synchronization of the ART and create confusion and uncertainty.

 The system demo is the best measure of progress for complex system development because it provides an integrated, comprehensive view of the new features delivered by the Agile Release Train (ART) over the past iteration. The system demo offers the ART a fact-based measure of current, system-level progress within the Program Increment (PI). It also allows the stakeholders to give feedback on the solution’s fitness for purpose and alignment with the vision. The system demo tests and evaluates the complete solution in a production-like context to receive feedback from stakeholders, including Business Owners, executive sponsors, other Agile Teams, development management, and customers (and their proxies). References: System Demo - Scaled Agile Framework, Principle #4 - Build incrementally with fast, integrated learning cycles - Scaled Agile Framework

SAFe recommends running a Retrospective on a cadence during the PI for SAFe Team Kanban Teams. A Retrospective is a team-level event that occurs at the end of each iteration, where the team reflects on how they are working and identifies improvement actions for the next iteration. A Retrospective helps the team pursue perfection by applying the Plan-Do-Check-Adjust (PDCA) cycle1. SAFe Team Kanban Teams also participate in other ART events, such as PI Planning, System Demo, and Inspect and Adapt2. References: 1: Retrospective - Scaled Agile Framework2: SAFe Team Kanban - Scaled Agile Framework

Roadmaps are a visual tool that assists in the development and communication of planned deliverables, milestones, and investments over time and help distinguish different types of work1. Roadmaps are the glue that links strategy to execution and offer the ability to develop, evolve and adjust planned activities1. Roadmaps communicate intent, not commitment, as they are subject to change based on feedback, learning, and market conditions1. Roadmaps are not fixed at PI boundaries, but rather are updated frequently to reflect the current state of the solution and the environment1. Roadmaps provide multiple planning horizons, such as near-term, mid-term, and long-term, to show how the solution will evolve over time1. References: 1: Roadmap

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. Teams then reflect and identify improvement backlog items via a structured, problem-solving workshop. The I&A event consists of three parts: the PI System Demo, where the features developed during the PI are shown and feedback is collected; the quantitative and qualitative measurement, where the teams assess their performance and progress using various metrics and surveys; and the retrospective and problem-solving workshop, where the teams identify and analyze the root causes of their most critical issues and devise action plans to address them12. References: Inspect and Adapt, Exam Study Guide: SP (6.0) - SAFe® Practitioner

Differentiating business objectives are those that provide competitive differentiation and strategic advantage for the enterprise. They reflect the unique value proposition and vision of the enterprise and guide the portfolio strategy and decision-making. One example of differentiating business objectives is Strategic Themes, which are portfolio-level business objectives that connect a portfolio to the strategy of the enterprise. They are written in Objective and Key Result (OKR) format and influence the vision, budget, and backlogs for the portfolio, large solution, and program levels. They also provide business context and alignment for the agile teams and ARTs in the portfolio. References: Strategic Themes, SAFe 4.5 Reference Guide: Scaled Agile Framework for Lean Enterprises, How to use GOST + SAFe to increase your company’s agility

= The four core values of SAFe are alignment, built-in quality, transparency, and program execution. They represent the fundamental beliefs that are key to SAFe’s effectiveness and guide the behaviors and actions of everyone participating in a SAFe portfolio. Alignment ensures that everyone is working toward a common direction and strategy. Built-in quality ensures that every element of the solution meets the appropriate quality standards. Transparency fosters trust and collaboration among all stakeholders and enables fast and effective decision making. Program execution ensures that the value is delivered to the customers in the shortest sustainable lead time. References: = Core Values - Scaled Agile Framework, Scaled Agile Framework: Understand SAFe and Its 4 Core Values

Learn more

1blob:https://www.bing.com/5f02f69b-a399-4b02-bd9d-1ca455b2a924

scaledagileframework.com2plutora.com3blob:https://www.bing.com/fca59462-bab7-4f18-94fb-ded5185f4863

v5.scaledagileframework.com4premieragile.com5blob:https://www.bing.com/5f02f69b-a399-4b02-bd9d-1ca455b2a924

scaledagileframework.com

1of30

One of the recommended ways of splitting Features into Stories during a PI Planning event is to use the horizontal slicing technique, which means implementing the simplest variant of the functionality first and then adding more complexity and variations as enhancements. This technique helps to deliver value incrementally, reduce risk, and enable fast feedback and learning. Horizontal slicing also supports the application of the Minimum Viable Product (MVP) and Minimum Marketable Feature (MMF) concepts, which aim to deliver the smallest amount of functionality that can provide value and validate assumptions. References: Exam Study Guide: SP (6.0) - SAFe® Practitioner, Feature, Story

 A Feature is a service that fulfills a stakeholder need and delivers business value. One key component of a Feature is the benefit hypothesis, which is a statement that describes the expected outcome and value of the Feature for the end user or the business1. The benefit hypothesis helps to define the scope, priority, and acceptance criteria of the Feature, and to measure its impact and effectiveness after implementation2. The benefit hypothesis also supports the Lean UX process model, which includes a definition of the Minimum Marketable Feature (MMF), a benefit hypothesis, and acceptance criteria3. The other options are not key components of a Feature, although they may be related to it. A business plan is a document that outlines the goals, strategies, and financial projections of a business or a product, and it may include some features, but it is not a component of a Feature. Key stakeholders are the people or groups who have an interest or influence in the product or the Feature, and they may provide input or feedback, but they are not a component of a Feature. A release plan is a schedule that shows when the product or the Feature will be delivered to the customers or users, and it may depend on the Feature, but it is not a component of a Feature. References: Features and Capabilities - Scaled Agile Framework, What Are The Minimum Requirements For A Feature? SAFe, Agile - airfocus, Lean UX - Scaled Agile Framework

A servant leader is someone who puts the needs of others first and helps them develop and perform to their highest potential. The RTE is a servant leader who listens and supports teams in problem identification and decision-making, by facilitating ART events and processes, communicating with stakeholders, escalating impediments, and helping manage risk. The RTE also leads by example, by demonstrating the Lean-Agile mindset and values, fostering a culture of collaboration and innovation, and driving relentless improvement.

A technical exploration enabler is a type of enabler that supports research, prototyping, and other activities needed to develop an understanding of customer needs, including the exploration of prospective solutions and evaluation of alternatives1. A technical exploration enabler can be demonstrated by showing the knowledge gained by the exploration, such as the results of experiments, the insights from data analysis, the feedback from customers or stakeholders, the lessons learned from failures, or the recommendations for future actions2. Showing the knowledge gained by the exploration helps to validate the assumptions and hypotheses, measure the value and feasibility of the solution, and inform the decision-making process3. The other options are not valid ways to demonstrate a technical exploration enabler, as they either do not reflect the purpose of the exploration, or imply that the exploration is not necessary or valuable. References: Enablers - Scaled Agile Framework, How can a technical exploration enabler be demonstrated?, Principle #4 - Build incrementally with fast, integrated learning cycles - Scaled Agile Framework

The Team and Technical Agility Core Competency describes the critical skills and Lean-Agile principles and practices that high-performing Agile teams and Teams of Agile teams use to create high-quality solutions for their customers. It consists of three dimensions: Agile Teams, Team of Agile Teams, and Built in Quality1. Built in Quality is the dimension that ensures that every aspect of the solution, from code to compliance, is designed and implemented with high standards and practices that guarantee quality. Built in Quality enables fast and reliable delivery of value, reduces waste and rework, and fosters a culture of continuous improvement. Some of the practices that support Built in Quality in SAFe are Test-First, Behavior-Driven Development, Acceptance Test-Driven Development, Continuous Integration, Continuous Deployment, and Communities of Practice2. References: Team and Technical Agility - Scaled Agile Framework, Built-In Quality - Scaled Agile Framework.

One of the results from Iteration Planning for SAFe Scrum Teams is the Iteration goals, which are short, specific, and measurable statements that describe what the Agile team intends to accomplish in an Iteration. The Iteration goals are derived from the team backlog, the PI objectives, and the team vision. The Iteration goals help to align the team to a common vision of work in the Iteration, and provide clarity, focus, and motivation. The Iteration goals also enable the team to communicate their progress and dependencies to other teams and stakeholders, and to demonstrate value delivery in the system demo. References: Exam Study Guide: SP (6.0) - SAFe® Practitioner, Iteration Goals

 = Making quality everyone’s responsibility is critical to successfully implementing quality in a Lean-Agile environment. This means that all the people involved in creating and delivering value to the customer, from business functions to software applications, share the same quality standards and practices. Quality is not something that can be delegated or outsourced to a separate team or department. It is embedded in the culture, mindset, and behavior of every individual and team. Making quality everyone’s responsibility enables faster feedback, continuous improvement, and higher customer satisfaction12. References: = 1: Built-In Quality - Scaled Agile Framework2; 2: How to Implement Quality in a Lean-Agile Environment Successfully1

n: = Separating release elements from the Solution means identifying specific release elements, such as Features or components, that can be released independently of the entire Solution. This technique provides several benefits, such as1:

It enables faster delivery of value to customers by releasing the most important or urgent elements first

It reduces the risk of releasing complex or interdependent elements that may cause errors or failures

It allows for more flexibility and responsiveness to changing customer needs and market conditions

It supports continuous integration and deployment by allowing smaller and more frequent releases

The role of the Scrum Master in SAFe is to act as a servant leader who helps teams self-organize, self-manage, and deliver using effective Agile practices. The Scrum Master educates the team on various frameworks and methods, including Scrum, Kanban, Extreme Programming, and SAFe, ensuring that the agreed-upon Agile process is followed. The Scrum Master also helps remove impediments, facilitates team and program events, coaches the team and stakeholders on how to apply the SAFe principles and values, and fosters an environment of continuous improvement and high performance. References: Scrum Master - Scaled Agile Framework, SAFe Scrum Master Roles and Responsibilities - KnowledgeHut

 The ART Planning Board, also known as the Program Board, is a visualization of the PI’s feature delivery dates, feature dependencies among teams, and relevant milestones. The primary purpose of the ART Planning Board is to show dependencies between teams relating to the Feature development, so that they can be identified, managed, and resolved during PI Planning and execution. The ART Planning Board also helps align teams and stakeholders to a shared mission and vision, and provides transparency and visibility into the ART’s progress and risks. References: ART Planning Board, PI Planning, Exam Study Guide: SP (6.0) - SAFe Practitioner

 Story Mapping is a design-thinking technique that helps break down Features while considering the end-to-end user flow. It is a collaborative practice that visually maps the user journey and the activities that the user performs to reach a desired outcome. Story Mapping helps teams understand the user needs, prioritize the backlog, and plan the iterations and PIs. References: Story Mapping, Story, Exam Study Guide: SP (6.0) - SAFe® Practitioner

The System Demo is a significant event that provides an integrated view of new features for the most recent iteration delivered by all the teams in the Agile Release Train (ART). Each demo gives ART stakeholders an objective measure of progress during a Program Increment (PI) and the opportunity to give feedback on the solution. The System Demo is the one real measure of value, velocity, and progress of the fully integrated work across all the teams. The purpose of the System Demo is to demonstrate new functionality, not to evaluate the full PI, introduce new architectural designs, or identify PI Objectives. Those activities are done in other events, such as the Inspect and Adapt, the Architectural Runway, and the PI Planning. References: System Demo, System Demo - Scaled Agile Framework, Why System Demo Considered A Significant Event In SAFe®? - Learnow, System Demo - Scaled Agile Framework.

 An Agile Team collects the Iteration Metrics they have agreed upon during the quantitative part of the team retrospective. This is the part where the team assesses whether they met the Iteration Goals using a binary (yes or no) measure, and reviews the metrics that provide visibility and insight into the team’s performance and process improvement. Examples of Iteration Metrics include flow metrics, such as flow velocity, load and distribution, defects addressed, and automated test coverage. The team uses these metrics to identify trends, patterns, and areas for improvement, and to inform their qualitative feedback and improvement stories. References: Iteration Retrospective - Scaled Agile Framework, Metrics - Scaled Agile Framework

 The definition of done (DoD) is a set of criteria that a product increment must meet for the team to consider it complete and ready for customers. It is a shared understanding among the team members of when a product increment is ready for release, even when the increment is large and consists of many items. The DoD is a commitment that the scrum team makes regarding the quality of the increment. The team promises that each increment will meet the DoD. They have checked all the quality checkboxes. This allows stakeholders to be confident that each new increment is usable and valuable. The DoD is not created by one person, but by the entire project team, including developers, testers, product owners, and other stakeholders. This ensures a smoother process during sprints since everyone is using the DoD as a guide alongside any checklists before marking an item as complete. Therefore, the agile teams are the primary stakeholders who develop the DoD for the team increment. References: What is the Definition of Done? Understanding DOD in Agile - Atlassian, What is the Definition of Done? | Scrum.org, How To Create A Definition Of Done | Agile Learning Labs, What is a Definition of Done? | Scrum.org

According to the Lean-Agile Leadership competency of SAFe, management must commit to quality and take responsibility to change the system for a successful Agile transformation. This means that leaders must lead by example, learn and model the Lean-Agile mindset, values, principles, and practices, and lead the change to a new way of working. They must also empower and engage individuals and teams to reach their highest potential, and create a culture of relentless improvement and innovation1. Management cannot delegate or outsource the responsibility of leading the Agile transformation, as they are the ones who have the authority and influence to change and improve the systems that govern how work is performed2. References: 1: Lean-Agile Leadership - Scaled Agile Framework2: What Must Management Do for a Successful Agile Transformation?

During the draft plan review, teams present their preliminary plans for the upcoming PI, including their iteration goals, capacity and load, and risks and impediments1. Iteration goals are a set of SMART objectives that provide a clear vision and alignment for each iteration2. They also help teams communicate their progress and dependencies to other teams and stakeholders during the PI planning event3. References: PI Planning, Iteration Goals, Presenting PI Planning Draft and Final Plan Reviews

 Story point size is a relative measure of the effort and complexity involved in implementing a user story. It is not based on the team size, the number of days it will take, or the priority of the story. Rather, it is based on the comparison of the story with other stories of similar or different sizes. Story points help teams estimate how much work they can complete in an iteration, based on their past performance and current capacity. Story points also help teams plan and track their progress at the program level, by aligning the features and capabilities with the stories that implement them. References: Story - Scaled Agile Framework, A Guide to Story Point Estimation - DEV Community, What should be taken into account when estimating Story poin - Madanswer

A user story is a work type that is defined as “a short description of a small piece of desired functionality written in the user’s language” in SAFe. A user story is a primary artifact used to define system behavior in Agile. It is a simple and concise way of expressing the user’s needs and expectations from the system. A user story typically follows the format of “As a [role], I want [functionality], so that [benefit]”. A user story also has acceptance criteria and acceptance tests that specify how the functionality will be verified and validated. A user story is intended to enable the implementation of a small, vertical slice of system behavior that supports incremental development. A user story is maintained and prioritized in the team backlog by the product owner1. References: Story - Scaled Agile Framework

According to the Scaled Agile Framework, the ART Planning Board is a visualization of the PI’s feature delivery dates, feature dependencies among teams, and relevant milestones1. Features are the primary elements that are planned and tracked on the ART Planning Board2.

Epics, user stories, and tasks are not found on the ART Planning Board, but they are related to features in different ways. Epics are large initiatives that span multiple ARTs and PIs, and they are decomposed into features and enablers2. User stories and tasks are smaller units of work that are used by teams to implement features within iterations2.

 An Iteration retrospective is a meeting that occurs at the end of each Iteration, where the Agile team reflects on their performance, identifies what went well and what can be improved, and agrees on action items to implement in the next Iteration. One of the essential parts of an Iteration retrospective is the team discussion around opportunities for continuous improvement, where the team members share their observations, feedback, and suggestions, and collaborate to find solutions for the challenges they faced. This part of the retrospective helps the team to learn from their experience, enhance their processes and practices, and increase their effectiveness and efficiency. References: Exam Study Guide: SP (6.0) - SAFe® Practitioner, [Iteration Retrospective]

 = WIP limits are necessary in the ART Kanban to ensure large queues are not forming, which would slow down the flow of value and increase the lead time. WIP limits are a way of applying the Lean principle of reducing waste and optimizing the system for the whole. By limiting the amount of work that can be in progress at any stage of the Kanban system, the ART can balance the demand and capacity, avoid overloading the system, and focus on completing the work rather than starting new work. WIP limits also help to expose bottlenecks, dependencies, and impediments that need to be resolved to improve the flow efficiency and quality of the work. References: = ART Flow - Scaled Agile Framework, ART and Solution Train Backlogs - Scaled Agile Framework, Kanban And The Importance Of Work In Progress (WIP) Limits

 Continuous Deployment is the process of releasing every good build to users through a delivery pipeline that performs various tests, deployments, and validations1. Deploy, verify, monitor, and respond are the four activities of Continuous Deployment that ensure the quality and reliability of the software2. References: 1: Continuous Deployment2: Exam Study Guide: SP (6.0) - SAFe® Practitioner

An ART event is a meeting or ceremony that involves all the teams in an Agile Release Train (ART) and helps them align, collaborate, and deliver value. An example of an ART event is the Innovation and Planning (IP) Iteration, which is a two-week period at the end of each Program Increment (PI) that provides time for innovation, planning, and improvement activities. During the IP Iteration, teams can explore new ideas, work on technical debt, conduct hackathons, prepare for the next PI Planning, and conduct the Inspect and Adapt workshop. References: Agile Release Train, Scaled Agile: ART Events Overview, Innovation and Planning Iteration

 SAFe recommends using a second operating system to deliver value by creating a dual operating system that consists of a Network and a Hierarchy. The Network is optimized for speed and adaptability, while the Hierarchy is optimized for efficiency and stability. The Network is composed of development value streams (DVSs) that are realized by product-focused Agile Release Trains (ARTs). The ARTs are cross-functional teams that work together to deliver software products on a regular schedule. The Hierarchy provides the necessary support and governance for the Network, such as operations, HR, finance, and compliance. By using a second operating system, SAFe enables business agility by allowing the organization to organize and reorganize around the flow of value, while maintaining the benefits and stability of the existing hierarchical structure. References: Business Agility, Principle #10 – Organize around value, How Does SAFe Enable Business Agility Through A Second Operating System, How does safe provide a second operating system that enables business agility

Value is the first and most important pillar in the House of Lean, which is a model that guides the Lean-Agile transformation and culture. Value means delivering the maximum benefit to the customer in the shortest sustainable lead time, while providing the best quality and lowest cost possible1. Value is the ultimate goal of the House of Lean, and it is achieved by applying the other pillars: innovation, relentless improvement, leadership, and respect for people and culture2. Value is also the foundation of the Lean-Agile mindset, which is the way of thinking and acting that enables Business Agility3. Value focuses on the customer as the consumer of the work, and requires understanding and meeting their needs, expectations, and desires4. References: = 1: SAFe Core Values - Scaled Agile Framework1; 2: The SAFe House of Lean model: short and sweet - Echometer2; 3: Lean-Agile Mindset - Scaled Agile Framework3; 4: Exploring Which Pillar in the House of Lean Focuses on the Customer4

ART Sync is an event that SAFe recommends running regularly throughout the PI. ART Sync is a weekly meeting that brings together the key roles of the Agile Release Train (ART), such as the Release Train Engineer (RTE), the Product Management, the System Architect/Engineer, the Business Owners, and the Scrum Masters. The purpose of ART Sync is to review the progress and status of the ART, identify and resolve impediments and dependencies, coordinate cross-team and cross-ART activities, and align on the vision and objectives of the PI. ART Sync helps the ART maintain alignment, collaboration, and synchronization, and enables fast feedback and continuous improvement. References: ART Sync - Scaled Agile Framework, SAFe for Teams Student Workbook: materials and exercises from Lesson 6

The Product Owner (PO) in the team is responsible for sequencing backlog items to program priorities, events, and dependencies. The PO works with the Product Manager, who owns the Vision and the Roadmap, to define and sequence the features in the Program Backlog1. The PO also collaborates with other POs in the Agile Release Train (ART) to manage dependencies and ensure alignment across teams2. The PO maintains and prioritizes the Team Backlog, which is the single source of truth for the upcoming features of the system3. The PO also participates in the Program Increment (PI) Planning, where the team’s PI objectives are aligned with the program priorities and dependencies4. References: Product Owner - Scaled Agile Framework, Team Backlog - Scaled Agile Framework, Program Backlog - Scaled Agile Framework, PI Planning - Scaled Agile Framework

The PI System Demo is a significant event that provides an integrated view of new Features for the most recent Iteration delivered by all the teams in the Agile Release Train (ART). Each demo gives ART stakeholders an objective measure of progress during a Program Increment (PI). A system demo is a critical event. It’s the method for assessing the Solution’s current state and gathering immediate, Agile Release Train -level feedback from the people doing the work, as well as critical feedback from Business Owners, sponsors, stakeholders, and customers. The feedback is critical, as only they can give the guidance the ART needs to stay on course or make adjustments. Therefore, the system demo is intended for the Business Owners, who are key stakeholders that have the ultimate responsibility for the Return on Investment (ROI) of the solution1. References: System Demo - Scaled Agile Framework

Iteration planning, Iteration review, and backlog refinement are examples of team events, which are events that occur within the Agile team to plan, execute, and improve their work. Team events are aligned with the Iteration cadence, which is typically two weeks. Team events include:

Iteration planning: A meeting where the team reviews the team backlog, estimates the stories, and commits to the Iteration goals

Daily stand-up: A 15-minute meeting where the team members synchronize their work, share their progress, and identify any impediments or dependencies

Backlog refinement: An ongoing activity where the team and the Product Owner collaborate to refine the team backlog, split features into stories, write acceptance criteria, and prioritize the work

Iteration review: A meeting where the team demonstrates the completed stories to the Product Owner and other stakeholders, and collects feedback and validation

Iteration retrospective: A meeting where the team reflects on their performance, identifies what went well and what can be improved, and agrees on action items to implement in the next Iteration

Team events are different from PI events, which are events that occur at the program level and involve all the teams and stakeholders of an Agile Release Train (ART). PI events include:

PI planning: A two-day event where the ART aligns on a common vision, mission, and goals for the upcoming Program Increment (PI), and creates a plan for delivering value

System demo: A meeting where the ART demonstrates the integrated solution to the Business Owners and other stakeholders, and collects feedback and validation

Inspect and Adapt (I&A): A one-day event where the ART reviews the PI results, identifies the strengths and weaknesses, and creates an improvement backlog for the next PI

Team events are also different from sync events, which are events that occur at the large solution level and involve multiple ARTs and Solution Trains that are working on a complex solution. Sync events include:

Solution demo: A meeting where the Solution Train demonstrates the integrated solution to the Customers and other stakeholders, and collects feedback and validation

Pre- and Post-PI planning: Meetings where the Solution Train aligns on a common vision, mission, and goals for the upcoming PI, and coordinates the dependencies and risks across the ARTs

Solution I&A: A meeting where the Solution Train reviews the PI results, identifies the strengths and weaknesses, and creates an improvement backlog for the next PI

Team events are also different from program events, which are events that occur at the portfolio level and involve the Portfolio Management and other strategic roles. Program events include:

Portfolio sync: A meeting where the Portfolio Management reviews the portfolio vision, strategy, and roadmap, and aligns the value streams and ARTs on the portfolio priorities and objectives

Lean budget guardrails: A set of policies and guidelines that govern the allocation and spending of the portfolio budget across the value streams and ARTs

Portfolio Kanban: A system that visualizes and manages the portfolio work items, such as epics and capabilities, and ensures that they are aligned with the portfolio strategy and value delivery References: Exam Study Guide: SP (6.0) - SAFe® Practitioner, Team Events, PI Events, Sync Events, [Program Events]

 Empathy maps are a design thinking tool that promotes customer identification by helping teams develop a deep, shared understanding of others. They enable teams to imagine what a specific persona is thinking, feeling, hearing, and seeing as they use the solution. Empathy maps help teams to design with empathy, which is a key behavior of customer centricity. Empathy maps can be used to explore different aspects of the problem and solution space, and to validate assumptions and hypotheses about the customer’s needs and preferences. References: Design Thinking, Customer Centricity

The team’s initial capacity is calculated by multiplying the number of team members by the number of hours per day they are available for work, and then by the number of days in the iteration. In this case, the team has six members (two testers, three developers, and one Scrum Master/Team Coach), and the Product Owner is split between two teams, so they only count as half a member. Assuming they are available for eight hours per day and the iteration is five days long, the team’s initial capacity is:

Initial capacity=(6+0.5)×8×5=260

However, this is not the final answer, because the team also needs to account for the time spent on non-value-added activities, such as meetings, emails, and other overhead. According to the SAFe for Teams course, a typical team spends about 15% of their time on these activities, so they need to subtract that from their initial capacity. Therefore, the team’s final capacity before calculating for time off is:

Final capacity=260×(1−0.15)=221

To get the answer in terms of story points, the team needs to divide their final capacity by the average number of hours per story point. According to the SAFe for Teams course, a typical team has an average of 5.5 hours per story point, so the team’s capacity in story points is:

Capacity in story points=5.5221​≈40

Therefore, the correct answer is C. 40.

SAFe Team Kanban is a method that enables teams to manage their flow of work using a visual board and a set of policies. It is especially suitable for teams that have unpredictable or interrupt-driven work, such as maintenance, support, or operations teams1. SAFe Team Kanban helps teams to visualize their work, limit their work in progress (WIP), measure and improve their flow, and implement feedback loops2. Team A is a maintenance team that cannot always predictably plan their work. They like to meet daily to review the needs of the system and plan for how they can quickly address those needs during the workday. Therefore, SAFe Team Kanban is the most appropriate SAFe Lean-Agile method for Team A to plan and execute their work. References: Team Kanban - Scaled Agile Framework, SAFe Lean-Agile Principles - Scaled Agile Framework

SAFe Team Kanban is a method that helps teams facilitate the flow of value by visualizing workflow, establishing Work In Process (WIP) limits, measuring throughput, and continuously improving their process1. It is suitable for teams that have a rapid and uneven arrival of work and fast-changing priorities, such as maintenance teams2. The other options are not appropriate for Team A’s context. SAFe Platform Team is organized around developing and supporting platforms that provide services to other teams3. SAFe Enabling Team is organized to assist other groups with specialized capabilities and help them become proficient in new technologies4. SAFe XP Team is an Agile Team method that combines the power of Scrum with Extreme Programming (XP) practices and operates within the ART iteration cadence5.