Scrum: SAFe Considerations

Scrum was introduced to address the unacceptably high failure rate of software projects. Software development projects can have highly unpredictable outcomes due to the complexity of the problems being addressed and because they often have goals that change over time. Scrum is based on Empirical Process Control supported by the principles of Inspection and Adaptation. Empirical simply refers to an approach to problem-solving based on experimentation. An empirical approach is necessary for work that is not easily amenable to analytical or predictive planning. In this type of work it is typically not possible to know in advance all of the required input variables, or the relationships between input variables and outcomes.   Examples of this type of endeavor include software development, scientific research, economic forecasting and perhaps police detective work.  In these cases, planning is ideally based on an adaptive approach as opposed to an analytical or predictive one. Cause and effect may only be obvious in retrospect, and thus progress is best made by solving one small problem at a time, and then building incrementally on that learning, adapting both process and the solution itself along the way.   Contrast this with the problem of building construction where the design, required materials and labor can be completely specified up-front – this is an example of the analytical approach. Scrum is a system of short inspect and adapt cycles (or fast feedback loops) based on the PDCA (Plan-Do-Check-Adjust) cycle of Deming. Progress is made by only focusing on a small set of details within a narrow time-box, or iteration, called a sprint, at the end of which both the resulting product increment and process are inspected and appropriate adjustments defined for implementation in the next cycle. 

Empirical vs. Analytical

Empirical: Cause and effect relationships between problem variables not well understood. Problems solved by experimentation and observation. 

Analytical: Problem amenable to analysis or logic.

Think of scrum as a set of PDCA (Plan-Do-Check-Adjust) cycles, where the plan, the product and the process are constantly inspected and adjusted in order to arrive at the best possible solution:

  • Plan: Sprint Planning
  • Do: Execute the plan – construct the increment
  • Check & Adjust the Plan: Conduct a daily stand-up to check progress towards meeting the sprint goal, and if necessary, adjust the plan to ensure maximum user value is delivered at the end of the sprint.
  • Check & Adjust the Product: Conduct a Sprint Review, demonstrate (check) new product capabilities and get feedback from stakeholders. This review may result in changes (adjustments) to the product backlog.
  • Check & Adjust the Process: Conduct a Sprint Retrospective to check for gaps between sprint goals and actual accomplishments. Determine underlying root causes and identify corrective actions (adjustments) to the team’s development practices.

The scrum framework is usually represented in a chart like the following:

Scrum Framework
Scrum Framework

The official definition of Scrum by Ken Schwaber and Jeff Sutherland is documented in The Scrum Guide, and  runs to a grand total of 13 pages. Scrum is intended to be a customizable framework, not a prescription, and The Guide studiously avoids all references to techniques, methodologies, tools or tactics. The authors define scrum as: “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value”. And that, “specific tactics for using the scrum framework vary and are described elsewhere.” Hence, nowhere in the Scrum Guide will you find any reference to User Stories, TDD, BDD, test automation, or continuous integration (let alone architectural runways or release trains, which we’ll get to later). These are considered to be tactics, which may or may not work in all situations, and hence have been appropriately omitted.

It is unfortunate that the scrum lexicon has been infused with terms like ‘velocity’ and ‘sprint’, as these can imply that scrum is primarily about speed of execution.  Scrum’s mechanisms for inspection and adaptation are what enable it to satisfy customers through early and continuous delivery of valuable software, while at the same time providing the flexibility to absorb changing requirements in support of customers’ competitive advantage.  

The Scrum Framework comprises four fundamental ceremonies or processes: Sprint Planning, Daily Scrum (or Daily Stand-Up), Sprint Review and Sprint Retrospective. Many teams include a fifth process – Backlog Refinement, which will also be described.  

SAFe Considerations

Scrum teams who are part of an Agile Release Train (ART), and are working to deliver SAFe Program Increments (PI’s) operate in a much broader context than that of the sole scrum team working from a single product backlog. All of their core work practices: Sprint Planning, Daily Stand-Ups, Sprint Reviews and Retrospectives, will be need to take into account the broader context of the current Program Increment, and it’s associated PI Objectives. They will need to interact with different roles defined by the SAFe framework, and will need to be familiar with additional artifacts defined by SAFe. In the following articles we will describe some of the key considerations that teams need to account for as they collaborate with other SAFe teams to deliver Program Increments. 


With SAFe, the practices required to plan and execute fully integrated product increments are encapsulated in an outer program loop that has its own set of practices, devoted to delivering the PI objectives. The program-level practices serve the same purpose as those at the iteration level, except that they are focused on maximizing the value output from the entire release train. Like scrum, the SAFe program level runs as a PDCA cycle, with its own Inspect and Adapt (I&A)  activities. It is not represented like this in the SAFe literature, but is intended to operate in a similar way:

SAFe Program Framework
SAFe Program Framework

Iteration (Scrum)

Program (SAFe)


Sprint Planning

PI Planning

I&A The Plan

Daily Standup


I&A The Product

Sprint Review

System Demo

I&A The Process

Sprint Retrospective


At the program level, SAFe is a PDCA loop that delivers product increments based on the integrated output of multiple collaborating teams. Like scrum, check and adjust plays a central role in the process, where the plan, the product, and the process used to develop it are continuously reviewed and improved. 

In SAFe, the final iteration of each Program Increment is devoted to Innovation & Planning (IP).  The IP iteration culminates in an Inspect & Adapt (I&A) event which includes a demo of all of the objectives delivered in the PI, a scoring of those objectives by business stakeholders, and finally a PI retrospective and problem-solving workshop. This I&A event is the program-level equivalent of scrum’s sprint review and retrospective activities, and serves the same purpose. The event takes place typically on the last day of the IP Iteration, which is the day immediately before the PI Planning event for the next PI. Inspect and Adapt (I&A) activities also run throughout the Program Increment as a faster inner loop to ensure a timely reaction to problems or opportunities as they present themselves.  

Here’s a link to The Scrum Guide.

Print Friendly, PDF & Email