SAFe Scrum Master

One anti-pattern of the Inspect and Adapt (I&A) is to have no actionable improvement Features
created as a result of the problem-solving workshop. This is considered an anti-pattern because the
main goal of the I&A workshop is to identify and address the systemic issues that are limiting the
effectiveness of the Agile Release Train (ART). The workshop should produce one or more
improvement Features that are added to the ART backlog and prioritized for the next PI Planning
event. These Features should be SMART (Specific, Measurable, Achievable, Relevant, and Time-
bound) and aligned with the ART vision and goals. Without actionable improvement Features, the
ART will miss the opportunity to learn and improve from the feedback and data collected during the
PI.

Iteration Review - Scaled Agile Framework
Exam Study Guide: SSM (6.0) - SAFe® Scrum Master

One benefit of holding regular system demos is that execution can be measured across the whole ART. A 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). The system demo offers the ART a fact-based measure of current, system-level progress within the PI. It's the true measure of ART velocity and progress. Achieving this requires implementing the scalable engineering practices necessary to support Continuous Integration across the ART. By holding regular system demos, the ART can evaluate the quality, functionality, and usability of the solution, as well as identify and resolve any issues, risks, or dependencies. The system demo also provides an opportunity for feedback and learning from the customers, Business Owners, and other stakeholders, which can help the ART to align with the vision and goals, and to adapt to changing needs and expectations. (Must be taken from SAFe 6 Scrum Master resources)

According to the Scaled Agile Framework (SAFe) 6.0 methodology, the correct statement about the team backlog is:

The team backlog is where the team refines possible Stories

Explanation

The team backlog is a prioritized list of work for the Agile Team. It includes:

• User Stories
• Defects
• Enablers

The team backlog is the property of the Agile Team and they are responsible for maintaining it. The team backlog is where the team refines possible Stories, not where they commit to work, finalize work, or accept Stories.

The process of refining Stories involves breaking down large Stories (also known as Epics) into smaller, more manageable pieces, and then further elaborating on these pieces as necessary. This process is also known as backlog grooming or backlog refinement.

Here is a simplified representation of the process:

Using the IP Iteration as intended can provide a significant benefit to the team by allowing them to focus on innovation, continuous improvement, and planning, which can lead to improved product quality and process efficiency.

The PI System Demo is performed during the Inspect and Adapt Event within the last iteration of a PI, which is called Innovation and Planning Iteration (IP Iteration).

The ''C'' in the CALMR approach to DevOps stands for culture, which is the foundation of successful DevOps adoption. Culture refers to the values, beliefs, and behaviors that guide the collaboration and alignment of everyone in the value stream. By creating a culture of shared responsibility, teams can manage the tensions caused by differing needs, such as speed, quality, security, and stability. A culture of shared responsibility means that everyone is accountable for the outcomes of their work, and that they work together to deliver value to the customers. It also means that teams respect each other's roles and expertise, and seek feedback and learning opportunities. A culture of shared responsibility fosters trust, transparency, and continuous improvement, which are essential for DevOps.

The Scaled Agile Framework (SAFe) 6.0 methodology identifies seven core competencies that are critical to achieving business agility. These competencies are:

1. Lean-Agile Leadership
2. Team and Technical Agility
3. Agile Product Delivery
4. Enterprise Solution Delivery
5. Lean Portfolio Management
6. Organizational Agility
7. Continuous Learning Culture

From the options you provided, Agile Product Delivery and Built-in Quality are recognized as core competencies in the SAFe 6.0 methodology.

Here is a brief explanation of these two competencies:

• Agile Product Delivery: This competency is about delivering valuable outcomes in a lean, reliable, and continuous flow. It involves three dimensions: Customer Centricity and Design Thinking, DevOps and Release on Demand, and Developing on Cadence and Releasing on Demand.
• Built-in Quality: This competency ensures that each solution element, at every increment, meets appropriate quality standards throughout development. It involves five specific aspects: Flow, Architecture and Design Quality, Code Quality, System Quality, and Release Quality.

The other two options you provided, "Growth Mindset" and "Design Thinking Practices", are important aspects of the SAFe methodology, but they are not recognized as standalone core competencies. They are incorporated within other competencies. For example, Design Thinking is a part of the Agile Product Delivery competency, and Growth Mindset is a part of the Continuous Learning Culture competency.

One purpose of iteration goals is to align team members to a common purpose and vision. Iteration
goals are a high-level summary of the business and technical goals that an Agile Team agrees to
accomplish in an iteration. They help the team and the product owner to reach agreement on the
business value they intend to deliver, align their work to their team PI objectives, and ground
everyone on their shared purpose. Iteration goals also provide transparency and management
information, as well as support the coordination and dependency management of the Agile Release Train (ART).

The correct answer to your question is:

To identify how the Story can be validated

Explanation

In the Scaled Agile Framework (SAFe) 6.0 methodology, acceptance criteria serve as a set of conditions that a software product must meet to be accepted by a user, a customer, or other system. They are used to describe the functional and non-functional requirements of a feature (or "Story" in Agile terminology) and are defined by the product owner or business representative.

The main purpose of acceptance criteria is to provide clear guidelines on when the implemented story is considered "done". This means they are used to identify how the Story can be validated, ensuring that the developed feature meets the desired functionality and quality.

Here's a simplified version of your options in a table:

According to the Scaled Agile Framework (SAFe) 6.0 methodology, the correct answer is:

Work with team members to establish a team Kanban board

Explanation

The Scrum Master or Team Coach can help teams improve flow by working with them to establish a team Kanban board. This is a visual tool that helps teams manage their work and improve their workflow efficiency.

Here's why the other options are not as effective:

• Coach team members to combine work into bigger Stories: This could lead to larger, more complex work items that take longer to complete, potentially slowing down the flow.
• Direct team members to work in their domain of expertise: While this can improve individual productivity, it doesn't necessarily improve the overall team flow. It could also lead to silos within the team.
• Encourage hand-offs so each team member can write a Story to capture their piece of the work: This could lead to more hand-offs and dependencies, which can slow down the flow.

According to the Scaled Agile Framework (SAFe) 6.0 methodology, the absence of DevOps can lead to several issues. However, based on the options provided, the most relevant issue is:

Challenges between teams that build Solutions and those who operate the Solutions

This is because DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality. Without DevOps, there can be a disconnect between the teams that build the solutions and those who operate them, leading to inefficiencies and potential issues in the software development process.

Here's the answer in a table format:

A Team's velocity is calculated by summing up the points of the fully completed stories, so it’s 8+1=9 points, excluding story C which is not completed 100%.

One way a Scrum Master/Team Coach can support productive team Backlog Refinement sessions is to ensure subject matter experts are invited. Subject matter experts (SMEs) are people who have specialized knowledge or skills related to the domain or technical aspects of the product or solution. They can provide valuable input and feedback to the team during Backlog Refinement, such as clarifying requirements, validating assumptions, identifying dependencies, and suggesting solutions. SMEs can also help the team to split, estimate, and prioritize the backlog items more effectively and accurately. By inviting SMEs to the Backlog Refinement sessions, the Scrum Master/Team Coach can facilitate better collaboration, communication, and alignment among the team and the stakeholders. (Must be taken from SAFe 6 Scrum Master resources)

According to SAFe, one output of a successful Iteration Retrospective is the creation of a few improvement Stories that enter the Team Backlog for the next iteration. These stories reflect the team’s agreement on what they can do better in terms of their process, practices, and performance. The improvement stories are visible and prioritized along with the other stories in the backlog. They help the team implement the concept of relentless improvement, which is one of the core values of SAFe.

References: Iteration Retrospective - Scaled Agile Framework, Exam Study Guide: SSM (6.0) - SAFe® Scrum Master

According to the Scaled Agile Framework (SAFe) 6.0 methodology, the responsibility of a Scrum Master/Team Coach among the options provided is:

Answer

• Supporting Iteration Execution

Explanation

The Scrum Master/Team Coach plays a crucial role in facilitating the team's progress towards team goals. The Scrum Master is a servant-leader for the Agile Team, helping to remove impediments and fostering an environment for high-performing team dynamics, continuous flow, and relentless improvement.

Here's a brief explanation of each option:

1. Supporting Iteration Execution: This is a core responsibility of the Scrum Master. They facilitate the team's progress towards iteration goals.
2. Assigning points for each user story: This is typically a team responsibility, not specifically the Scrum Master's. The team collectively estimates the effort for each user story in the backlog.
3. Accepting completed work: This is typically the role of the Product Owner, not the Scrum Master. The Product Owner accepts user stories once they meet the acceptance criteria.
4. Attending PO Sync: While the Scrum Master might attend this meeting, it is not a primary responsibility. The main attendees of the PO Sync are the Product Owners.

One example of an Agile Team development practice is to demo working functionality frequently to the product owner and other stakeholders. This practice helps the team to get fast feedback, validate their assumptions, and ensure that they are delivering value that meets the customer needs and expectations. Demoing frequently also helps the team to improve the quality of their work, as they have to ensure that the functionality is tested and meets the definition of done before showing it to others. Demoing frequently is part of the SAFe Scrum and SAFe Team Kanban practices, and is done at the end of each iteration in the Iteration Review event.

A constructive IP Iteration is one of the recommended practices for Scrum Masters/Team Coaches to help teams avoid burnout, address technical debt, and foster innovation. An IP Iteration is a unique, dedicated iteration that occurs every PI and provides an estimating buffer for meeting PI Objectives and dedicated time for innovation, continuing education, PI Planning, and Inspect and Adapt events. During the IP Iteration, teams can work on activities such as hackathons, research and design, spikes, refactoring, automation, training, and other improvement initiatives that are difficult to fit into a continuous, incremental value delivery pattern. An IP Iteration also allows teams to prepare for and participate in the PI Planning and Inspect and Adapt events, which are essential for alignment, collaboration, and learning across the ART. A constructive IP Iteration can improve the predictability and flow of value delivery, increase employee engagement and satisfaction, enhance the agility and resilience of the teams, and create a competitive advantage for the enterprise. (Must be taken from SAFe 6 Scrum Master resources)