The SSM (6.0) - SAFe Scrum Master Practice 6.0 (SSM)

The intended value of the Backlog Refinement event is that the team is able to prepare requirements for Iteration Planning.  Backlog Refinement is an ongoing process where the team collaborates with the Product Owner and other stakeholders to review, split, prioritize, and estimate the stories in the Team Backlog 1  One of the main objectives of Backlog Refinement is to ensure that the stories are ready for Iteration Planning, which means they are clear, feasible, testable, and small enough to be completed in a single Iteration 2  By doing so, the team can improve the quality, efficiency, and e f fectiveness of their work, as well as deliver value to the customers and the organization 1 2 3

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.

A servant leader is defined in SAFe® as someone who prioritizes the growth, well-being, and development of their team over personal or organizational agendas. Rather than exercising authority or control, servant leaders empower, support, and enable their teams to achieve autonomy and high performance.

Scrum Masters and Team Coaches embody this leadership style by removing impediments, fostering collaboration, and promoting a safe environment for experimentation and learning. The servant leader’s goal is to help the team reach its full potential, not to command or direct.

From SAFe guidance:

“Servant leaders focus on the growth and well-being of people and the communities to which they belong. They put the needs of others first and help people develop and perform as highly as possible.”

Therefore, the correct answer is A. A leader that prioritizes the needs and growth of the team over their own priorities.

In SAFe®, during PI Planning, each team defines PI Objectives — clear, measurable statements of intended business outcomes. Some objectives carry higher uncertainty or risk due to technical complexity, dependency, or unknown factors.

To manage such uncertainty, teams can classify these as uncommitted objectives. This approach maintains visibility and alignment while signaling to stakeholders that these objectives are goals the team will pursue but cannot guarantee delivery. This helps set realistic expectations without discouraging ambition or exploration.

From SAFe guidance:

“Teams identify some objectives as uncommitted when there is significant uncertainty. These are not included in the committed plan but are made visible to stakeholders.”

Therefore, the correct answer is B. Move it to uncommitted objectives, as this is the recommended SAFe practice for handling objectives with high uncertainty.

Within a SAFe Agile Release Train (ART) , all teams work together toward a common mission guided by a single Program Backlog . This shared backlog aligns every team’s work to the same vision, ensuring coordination and synchronization.

This structure fosters transparency, dependency management, and alignment across all teams, allowing them to collaborate effectively while maintaining autonomy within their scope. The ART operates under the principle of “aligning with a common mission and cadence.”

From SAFe guidance:

“All teams on an ART share a common vision and a single Program Backlog that defines the work necessary to realize that vision.”

Thus, the correct answer is D. A common mission using a single backlog.

According to the SAFe 6 Scrum Master documentation, one of the ways a servant leader can support team members in decision-making is by giving each team member the opportunity to contribute. This means that the servant leader encourages and facilitates the participation of all team members in the decision-making process, ensuring that everyone’s voice is heard and valued. By giving each team member the opportunity to contribute, the servant leader fosters a culture of collaboration, empowerment, and trust, as well as increases the quality and buy-in of the decisions.

In SAFe®, the team backlog is the source of work for the Agile Team and includes all the user stories, enablers, and defects that represent potential upcoming work. It is owned and managed by the team, often guided by the Product Owner, who ensures the backlog remains prioritized and ready for iteration planning.

A crucial ongoing activity related to the backlog is refinement (or backlog refinement)—the process of reviewing, clarifying, and breaking down backlog items into smaller, well-understood Stories that are ready for implementation. During this activity, the team collaborates to ensure backlog items have sufficient detail, appropriate acceptance criteria, and relative sizing estimates.

From SAFe guidance:

“The team backlog is the source for stories, enablers, and defects planned in iterations. Teams continuously refine the backlog to ensure upcoming work is well understood and ready for planning.”

Therefore, the correct answer is C. The team backlog is where the team refines possible Stories.

According to the SAFe 6 Scrum Master documentation, one of the potential root causes of Team Sync anti-patterns is the lack of collective ownership. Collective ownership means that the team members share responsibility for the quality and delivery of the team’s work. They collaborate, communicate, and coordinate their efforts to achieve the team goals. They also support each other, provide feedback, and resolve issues together.  When there is a lack of collective ownership, team members may exhibit some of the following Team Sync anti-patterns  1 :

Reporting to managers (status meetings): Team members use the Team Sync as a way to report their progress to the SM/TC or other managers, rather than to synchronize with their peers. This can create a hierarchical and command-and-control culture, where team members are not empowered to self-organize and self-manage.

Monologues: Team members give long and detailed updates that are not relevant or useful to other team members. This can make the Team Sync boring, inefficient, and ineffective, as team members lose interest and attention.

Cross-functional team standups (updates are not related to other people’s work): Team members work on different features or components that are not aligned with the team goals or the Iteration goals. This can result in silos, dependencies, and integration issues, as well as reduced collaboration and coordination.

“Nothing to report” can be a good thing: Team members say they have nothing to report, either because they have not done any work, or because they do not want to share their work with the team. This can indicate a lack of transparency, trust, and accountability, as well as a missed opportunity to get feedback and support from the team.

To overcome these anti-patterns, the SM/TC should coach the team on the purpose and value of the Team Sync, and help them adopt the best practices for effective Team Syncs, such as  2 :

Having a clear agenda and timebox

Focusing on the team goals and the Iteration goals

Asking the three key questions: What did I do yesterday? What will I do today? Do I have any impediments?

Using visual aids, such as task boards or Kanban boards, to track progress and identify issues

Encouraging active participation, collaboration, and feedback

Ending with clear action items and follow-ups

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.