SAFe Scrum

---

Note: For more on SAFe Scrum, please read the additional Framework articles in the Scrum series, including Scrum Master/Team Coach, Iterations, Iteration Planning, Iteration Goals, Iteration Review, and Iteration Retrospective

---

Definition: SAFe Scrum is an Agile method used by teams within an ART to deliver customer value in a short time box. SAFe Scrum teams use iterations, Kanban systems, and Scrum events to plan, execute, demonstrate, and retrospect their work.

Many teams use SAFe Scrum as their primary Agile Team process. However, they are not limited to Scrum and may also use SAFe Team Kanban. However, all SAFe teams apply Built-in Quality techniques and other practices and activities not defined in Scrum. SAFe Scrum teams cooperate with other Agile Teams and ART stakeholders, building and deploying Solutions that benefit its Customers.

This article describes how Agile Teams apply SAFe Scrum.

Details

Agile Teams applying SAFe Scrum follow a regular cadence of events to achieve a common objective, delivering value to the enterprise and its customers. Teams have the authority and autonomy to plan, execute and manage their work, make decisions within their scope, and adapt to changing conditions in the best way they see fit. SAFe Principle #9, Decentralize decision-making, ensures alignment, and fosters subtle and minimal management direction for SAFe Scrum teams.

Indeed, teams determine how they do their work and the scope they can commit to within the iteration time box. They create and refine backlog items, expressed as Stories and acceptance criteria, defining and committing to iteration goals. They then build, test and deploy the new functionality, and ensure built-in quality for each solution increment.

Moreover, since Scrum teams have all the roles and skills needed to develop and deliver increments of value, they are designed to operate with the minimum possible constraints and dependencies with other teams. The self-management and cross-functional nature of the Scrum team—along with constant communication, constructive conflict, and dynamic interaction — creates a more enjoyable, fun, and productive work environment.

The SAFe Scrum Cycle

Figure 1 illustrates the basic Scrum cycle using SAFe terminology (e.g. iteration vs. sprint). Each event within this cycle provides an opportunity to inspect progress and make mid-course corrections. These events are often held at the same time and place to reduce overhead.

The following sections provide an overview of this cycle.

Scrum Iterations and events, including Iteration Planning, Review, and Retrospective, are briefly described in the following sections and in more detail in SAFe articles.

Team Backlog

The Team Backlog holds all the upcoming work needed to advance the solution. Most of the work is captured by user stories, but other work and activities (e.g., training, support) may also be included. The team backlog will have been partially filled during PI Planning, and the teams will have established their PI Objectives. Teams continually refine the backlog to ensure it always contains some stories ready for implementation without significant risk or surprise. During backlog refinement, teams review upcoming user stories and Features (as appropriate) to define, discuss, estimate, and establish acceptance criteria for upcoming backlog items. Backlog refinement is a continuous process throughout the iteration.

Iteration

Iterations (Sprints) are the heartbeat of Scrum and create a rhythm for work within the larger PI timebox. All the work necessary to achieve the iteration—including planning, team sync, iteration review, and retrospective—occur within iterations. Each iteration is a standard, fixed-length timebox, typically two weeks in length.

The team delivers high-quality increments of value during the iteration as working, tested software, solutions, or other valuable artifacts. Iterations are continuous and sequential, and a new iteration starts immediately after the previous one.

Iteration Planning

Iteration Planning is the first event of the iteration. The Scrum Master/Team Coach typically facilitates this event. All team members collaborate to determine how much of the team backlog they can deliver during an upcoming iteration and summarize those stories into a set of iteration goals. The team records the resulting plan in the iteration backlog. The Product Owner ensures that attendees are prepared to discuss the most critical team backlog items and how they map to the iteration goals and PI objectives. The Scrum team may invite other people to plan and provide advice.

Iteration planning addresses the following topics [2]:

• Why is this iteration valuable?
• What can be done in this iteration?
• How will the work get done?
• How will the chosen work get done?

Throughout iteration planning, the team elaborates on the acceptance criteria for each story and estimates the effort to complete it. The team selects candidate stories based on their available capacity for the iteration. For each selected item, the team plans the work necessary to create an increment of value that meets the definition of done (DoD), ensuring that it can be considered complete. The continuous development of incremental system functionality requires a scaled definition of done to ensure that work is done right (see the Scalable definition of done in the Built-in Quality article).

Iteration planning often requires decomposing backlog items into user or Enabler stories that can typically be completed in a day or two. The team decides how the work gets done within the iteration. Once planning is complete, the team commits to the work and records the iteration backlog in a visible place, such as a storyboard, Kanban board, or Agile project management tooling. Planning is timeboxed to a maximum of about two hours for a two-week iteration.

Iteration Goals

Iteration goals are a high-level summary of the business and technical goals an Agile Team agrees to accomplish in an iteration. They are vital to coordinating an ART as a self-organizing, self-managing team of Agile teams. Iteration goals provide the following benefits:

• Aligns team members to a common purpose
• Aligns teams to common ART PI Objectives and helps manage dependencies
• Provides transparency and management information

Once the team completes iteration planning and creates the iteration backlog, the team synthesizes the work for the next iteration as a set of iteration goals, which defines why the iteration is valuable. These goals are derived from the iteration backlog and aligned with the PI objectives. Optionally, the PO may define an initial set of goals before planning; this helps set the stage for the ‘why’ and ‘what’ of planning.

Iteration goals provide Agile teams, ART stakeholders, and management with information and a shared language for maintaining alignment, managing dependencies, and making necessary adjustments during the execution of the PI.

Iteration Backlog

During iteration planning, teams pull items from the team backlog to create the iteration backlog, containing the things they intend to complete in that iteration. Since PI planning is high-level, adjustments will likely need to be made for each iteration. Moreover, the teams get feedback—not only from their prior iterations but also from the System Demo and other teams with whom they collaborate. The local team’s concerns (defects, tech debt, and maintenance), ART backlog, and committed team PI objectives all influence the content of the iteration backlog.

Deliver

In SAFe, Scrum teams operate within the cadence and synchronization requirements of the ART, facilitating alignment, dependency management, and fast integrated learning cycles for the entire Solution.

During the iteration, each team collaborates to define, build, and test the stories they identified during iteration planning. They track the iteration’s progress and improve the flow of value by using story and Kanban boards and team sync events. They deliver stories throughout the iteration and avoid ‘waterfalling’ the timebox. They apply Built-In Quality practices to build the system right. These completed stories are demoed throughout the iteration and at the Iteration Review.

Team Sync

The team sync is a short meeting (usually 15 minutes or less), typically held about daily, to inspect progress toward the iteration goal, communicate, and adjust upcoming planned work. The team can use any structure or technique for the team sync, creating an action plan for coordinating the next workday. But the team sync is not the only time team members can make adjustments. The team collaborates and discusses adapting or re-planning work whenever needed.

High-performing teams use the team sync to find opportunities to help each other so that the team succeeds in delivering its committed iteration goals. The Scrum Master/Team Coach writes down topics that need further discussion on the ‘meet after’ board. Only the involved parties stay during the meet after to discuss these topics in more detail. Ineffective team syncs may be a symptom of deeper problems that require a systemic approach for resolution, which often becomes the responsibility of the Scrum Master/Team Coach.

Increment

The increment illustrated in Figure 1 represents how new solution functionality evolves within each iteration. Each increment is additive to all prior ones and verified, ensuring they all work together. Each is a working, tested, and usable solution that meets the agreed quality criteria in the definition of done (DoD). Further, the team can deliver multiple increments within an iteration. The sum of all the team’s increments is inspected at the iteration review.

Iteration Review

For Scrum Teams, the Iteration Review is the second to last event of the iteration. Each team inspects the outcomes of the iteration, presents the results of their work to key stakeholders, and assesses progress toward the iteration goal and PI objectives. It also determines any future adaptations to the product or process. Based on the results, stakeholders and the team collaborate on what to do next. The Team Backlog may also be adjusted to meet new opportunities. The iteration review is timeboxed to a maximum of 90 minutes for a two-week iteration.

Iteration Retrospective

The Iteration Retrospective is the last event of the iteration. Its primary purpose is to reflect on the iteration and derive new ideas to improve its process and the solution. The retrospective helps instill the concept of relentless improvement—one of the SAFe Core Values. The team discusses what went well, what problems it encountered, and how those problems were (or were not) solved. The team identifies the most helpful changes to improve. These changes are addressed as soon as possible or recorded in the backlog for the next iteration. The retrospective is timeboxed to a maximum of about 60 minutes for a two-week iteration.

Participating in the System Demo

The System Demo provides an integrated view of new features for the most recent iteration delivered by all the teams in the ART. Each demo gives ART stakeholders an objective measure of progress during the PI. Everyone on the ART participates or at least attends the system demo.

Tracking Progress

Using a Kanban board, the team tracks its iteration progress (Figure 2). Mature Scrum teams deliver stories throughout the iteration without ‘waterfalling’ the timebox.

SAFe Scrum Roles

The Scrum team’s size (typically ten or fewer) and structure optimize communication, interaction, and the ability to deliver value. “The Scrum team is small enough to remain nimble and large enough to complete significant work within a sprint [2].”

All SAFe Agile Teams, including those running Scrum, have two specialty team roles, each with a unique set of responsibilities (Figure 3):

• The Scrum Master/Team Coach (which may be a part-time role) is responsible for helping coordinate the flow of work to deliver to customers. They foster an environment for high performance and relentless improvement by coaching Scrum and Lean-Agile principles, helping remove impediments to progress, and facilitating team self-organization and self-management. Many SAFe Scrum Masters/Team Coaches have additional coaching responsibilities, such as coaching DevOps, Built-in Quality, Kanban, and flow.
• The Product Owner (typically a full-time role) understands the needs and expectations of customers. They serve as the team backlog content owner and prioritize the team backlog, helping to ensure the team is building the right thing in the right way.

Agile Teams are on the Train

Although teams are cross-functional, a single Agile Team may not be able to deliver complete end-user value for large systems that may include different technology platforms and a spectrum of disciplines such as hardware, software, and systems engineering. However, teams should strive to deliver end-to-end value as independently as possible to optimize flow. In support of the larger purpose, SAFe Agile teams operate within an Agile Release Train (ART), providing an environment for aligning and collaborating with other teams to build larger solutions and figure out how to reduce or eliminate dependencies and improve Team and ART Flow.

As part of the ART, all teams plan, demo, and learn together, as illustrated in Figure 4, which helps them focus on both local concerns and the larger aim of the ART. This alignment also enables teams to explore, integrate, deploy, and release value more independently.

The Agile Teams article further defines each team’s participation in this shared responsibility of delivering customer value.

---

Learn More

[1] Takeuchi, Hirotaka, and Ikujiro Nonaka. “The New, New Product Development Game,” Harvard Business Review, January 1986.

[2] Sutherland, Jeff, and Ken Schwaber. “The 2020 Scrum Guide,” Scrumguides.org.

Last Update: 12 April 2023