The ‘relay race’ approach to product development… may conflict with the goals of maximum speed and flexibility. Instead, a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.
—Hirotaka Takeuchi and Ikujiro Nonaka, “The New, New Product Development Game” [1]
Find a Course:
SAFe ScrumXP
SAFe ScrumXP is an Agile Team method used by Agile Release Trains (ARTs) to plan, execute, retrospect, and deliver customer value in a short time box. It combines the power of Scrum with Extreme Programming (XP) practices.Many teams use SAFe ScrumXP as their primary Agile team process. However, they are not limited to Scrum and may also use SAFe Team Kanban. However, within SAFe, all Agile Teams apply Built-in Quality techniques, Kanban to manage their backlogs, and other practices and activities not defined in Scrum. SAFe teams collaborate with other Agile Teams and ART stakeholders, building and deploying Solutions that benefit their Customers.
This article describes how Agile Teams apply SAFe ScrumXP.
Note: For more on applying ScrumXP in SAFe, please read the additional Framework articles in the Scrum series, including Scrum Master, Iterations, Iteration Planning, Iteration Review, and Iteration Retrospective.
Details
Agile Teams applying SAFe ScrumXP 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 and fosters alignment, and subtle, minimal management direction for Agile Teams. Indeed, teams determine how they do their work and the scope they can commit to within the time box. They create and refine backlog items, typically expressed as stories with 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 ScrumXP 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 ScrumXP team—along with constant communication, constructive conflict, and dynamic interaction —creates a more enjoyable, fun, and productive work environment.
The SAFe ScrumXP Cycle
Figure 1 illustrates the basic ScrumXP cycle, using SAFe terminology (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 the SAFe ScrumXP cycle.
Scrum Iterations and events, including Planning, Execution, the Daily Stand-up, Review, and Retro, are briefly described in the following sections and in more detail in SAFe articles of that name.
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 types of work and activities (e.g., training, support) may also be included. The team backlog will have been partially filled during PI Planning, and the team will have established the PI Objectives that align them to the mission of the ART. 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 stories and Features (as appropriate) to discuss, estimate, and establish preliminary acceptance criteria. Backlog refinement is a continuous process throughout the iteration.
Iteration
Iterations are the heartbeat of ScrumXP 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 SAFe Scrum Master 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 team may invite other people to plan and provide advice.
Iteration planning addresses the following topics [1]:
- Why is this iteration valuable?
- What can be done to deliver value?
- How will the work get done?
Throughout iteration planning, the team elaborates 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
Once the team completes planning and creates the iteration backlog, the team synthesizes the work for the next iteration as a set of Iteration Goals. They 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 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), Program Backlog, and committed team PI objectives all influence the content of the iteration backlog.
Execution
In SAFe, all teams deliver within the cadence and synchronization requirements of the Agile Release Train, 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 committed to during iteration planning. They track the iteration’s progress and improve the flow of value by using story and Kanban boards and daily stand-up (DSU) 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.
Daily Stand-Up
The Daily Stand-Up (DSU) is a short meeting (usually 15 minutes or less), typically held daily, which is used to inspect progress toward the iteration goals, communicate, and adjust upcoming planned work. The team can use any structure or technique to hold the DSU, creating an action plan for coordinating the next workday. But it’s not the only time team members can plan and make changes. The team collaborates and discusses adapting or re-planning work whenever needed.
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 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
The Iteration Review is the second to last event of the iteration, where each team, and its stakeholders, inspect the increment to assess progress toward the iteration goal and adjusts its backlog for the next iteration based on the outcomes and learning during the iteration review. The iteration review is a timeboxed working session, limited to a maximum of two hours 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 the increment and the process. The retrospective helps instill the concept of relentless improvement—one of the pillars of SAFe’s Lean-Agile Mindset. 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 typically timeboxed to a maximum of 45-90 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
In SAFe, Kanban systems manage the backlog and workflow at every level. The Kanban board for Agile Teams (Figure 2) reflects a team’s unique process for delivering value, tuned for the current workflow and capacity.
Built-In Quality
The importance of Built-In Quality cannot be overstated. It’s one of SAFe’s four Core Values. Quality begins at the code and component levels, with the people creating the solution. Otherwise, it’s difficult (or impossible) to ensure quality later, as the work is integrated and scales from component, to the system, to the full Solution. SAFe describes many engineering and quality practices that are inspired by Extreme Programming (XP):
- Continuous Integration
- Test-First (including Test-Driven Development and Behavior-Driven Development)
- Refactoring
- Pair work
- Collective ownership.
Some teams use other XP practices, such as pair programming, system metaphors, and more [3].
SAFe ScrumXP Roles
The team’s size 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].”
SAFe Agile Teams, including those running Scrum, have two specialty team roles, each with a unique set of responsibilities:
- The SAFe Scrum Master (which may be a part-time role) is responsible for helping coordinate the delivery of value to customers. They do this through coaching Lean-Agile principles, facilitating the removal of impediments to progress, creating effective team self-organization and self-management of the team, and fostering an environment of high performance and relentless improvement. The SAFe Scrum Master may have additional 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 and stakeholders. They serve as the team backlog content owner and prioritize work, helping to ensure the team is building the right thing. They collaborate with other teams on the train, enabling aligned priorities and sequencing of value delivery,
Agile Teams are on the Train
Although teams are cross-functional, it isn’t always realistic for a single Agile Team to deliver end-user value when a solution includes different technology platforms and a spectrum of disciplines such as hardware, software, and systems engineering. Typically, many more teams are required. Therefore, SAFe Agile teams operate within an Agile Release Train (ART), providing an environment for aligning and collaborating with other teams to build more extensive solution capabilities.
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 full customer value.
Learn More
[1] Nonaka and Takeuchi, The New, New Product Development Game, Harvard Business Review, January 1986. [2] Sutherland, Jeff, and Schwaber, Ken. The 2020 Scrum Guide, Scrumguides.org.
Last Update: 25 January 2023
