Luck is what happens when preparation meets opportunity.




Enablers support the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, infrastructure, compliance, and architecture development. They are captured in the various backlogs and occur at all levels of the Framework.


Enablers bring visibility to all the work necessary to support efficient development and delivery of future business requirements. Primarily, enablers are used for exploration, evolving the architecture, Compliance, and improving infrastructure. Since they reflect the real work (and sometimes plenty of it), they cannot remain invisible. Instead, they’re treated like all other value-added development activities—subject to estimating, visibility and tracking, Work in Process (WIP) limits, feedback, and presentation of results.

Type of Enablers

Enablers can be used for any activities that support upcoming business requirements, but generally, fall into one of four categories:

  • Exploration enablers – These support research, prototyping, and other activities needed to develop an understanding of Customer needs, including the exploration of prospective Solutions and evaluating alternatives.
  • Architectural enablers – These are created to build the Architectural Runway, which allows smoother and faster development.
  • Infrastructure enablers – These are created to build, enhance, and automate the development, testing, and deployment environments. They facilitate faster development, higher-quality testing, and a faster Continuous Delivery Pipeline.
  • Compliance enablers – These facilitate managing specific compliance activities, including Verification and Validation (V&V), documentation and signoffs, and regulatory submissions and approvals.

Creating and Managing Enablers

Enablers exist at all levels of the Framework and are written and prioritized to follow the same rules as their respective epics, capabilities, features, and stories.

  • Enabler Epics – Are written using the ‘Epic Hypothesis Statement’ format, in the same way as business epics. Enabler epics typically cut across Value Streams and Program Increments (PIs). To support their implementation, they must include a ‘Lean Business Case’ and are identified and tracked through the Portfolio Kanban system. Enabler epics may also occur at the Large Solution and Program Levels.
  • Enabler Capabilities and Features – Occur at the Large Solution and Program levels to capture work of that type. Since these enablers are a type of Feature or Capability, they share the same attributes, including a phrase, benefit hypothesis and acceptance criteria. They also must be structured to fit within a single PI.
  • Enabler Stories – Must fit in Iterations like any Story. Although they may not require the user voice format, their acceptance criteria clarify the requirements and support testing.

Enablers are often created by architects or by systems engineering at various levels. They might be Enterprise Architects at the portfolio level, or Solution and System Architects/Engineering at the large solution and program levels. These architects steer their enablers through the Kanban systems, providing the guidance to analyze them and the information to estimate and implement them.

To improve the existing solution, some enablers will emerge locally from the needs of the Agile Teams, Agile Release Trains (ARTs), or Solution Trains to ensure that enough emphasis is placed on furthering the solution and extending the architectural runway. Those that make it through the Kanban systems will be subject to capacity allocation in the Program and Solution Backlogs. This can be applied for enabler work as a whole, or it can distinguish between different types of enablers.

Using Enablers


Applying enablers for exploration provides a way for development teams to flesh out the details of requirements and design. The nature of Solution Intent is that many requirements begin as variables. After all, at the beginning of development little is known about what the customer needs or how to implement it. Customers themselves often don’t understand exactly what they want. Only through iterative product development and demos do they begin to figure out what they need.

On the solution side, there are many technical possibilities for how to implement a business need. Those alternatives must be analyzed and are often evaluated through modeling, prototyping, or even concurrent development of multiple solution options (also known as Set-Based Design).


The architectural runway is one of the constructs SAFe uses to implement the concepts behind Agile Architecture. The runway is the basis for developing business initiatives more quickly, on appropriate technical foundations. But the runway is constantly consumed by business epics, features, capabilities, and stories, so it must be maintained. Enablers are the backlog items used to maintain and extend the runway.

Some architectural enablers fix existing problems with the solution—for example, the need to enhance performance. These enablers start out in the backlog, but after implementation, they may become Nonfunctional Requirements (NFRs). In fact, many NFRs come into existence as a result of architectural enablers and tend to build over time, as can be seen in Figure 1.

Figure 1. Many NFRs appear over time as a result of enablers


Agile development is built on frequent integration. Agile teams integrate their work with other teams on the ART at the System Demos in every iteration. The trains integrate every PI for the Solution Demo. Many Enterprises implement Continuous Integration and Continuous Deployment to ensure that the solution is always running. This reduces the risk at the integration points and permits deployment and early release value.

To support such frequent or continuous integration and testing, there’s a need to develop infrastructure at the Team Level, program level, and large solution level. Agile teams, working with the System Team, are responsible for building and maintenance. Infrastructure enablers are used as backlog items to advance this work and continuously enhance it, both to support new scenarios and to enhance the agility of the enterprise.


By incrementally building the necessary artifacts in the solution content over a series of PIs, SAFe supports continuous verification and validation. Verification activities are implemented as part of the flow (e.g., backlog items or Definition of Done [DoD]). While the artifacts will satisfy the objective evidence needed at the end of development, they are created iteratively throughout the life cycle. Validation occurs when Product Owners, customers, and end users participate in ART planning and system demos, validating fitness for purpose.

For example, consider that regulations require design reviews and that all actions need to be recorded and resolved. The design review enabler backlog item offers evidence of the review, and its DoD ensures that actions are recorded and resolved according to the Lean Quality Management System (QMS). If needed, the actions themselves could be tracked as enabler stories. Regulations may also require that all changes be reviewed, which is addressed by a compulsory peer review DoD for all stories.

Implement Architectural Enablers Incrementally

The size and demands of architectural enabler work can make it overwhelming. So it’s important to remember that it needs to be broken down into smaller stories that fit in an iteration. This can be difficult, however, as architectural and infrastructure changes can potentially stop the existing system from working until the new architecture/infrastructure is in place. When planning enabler work, make sure to organize it so that the system can operate for most of the time on the old architecture or infrastructure. That way, teams can continue to work, integrate, demo, and even release while the enabler work is happening.

As described in System and Solution Architect/Engineering and in [1], there are three options:

  • Case A – The enabler is big, but there is an incremental approach to implementation. The system always runs (operates).
  • Case B – The enabler is big, but it can’t be implemented entirely incrementally. The system will need to take an occasional break.
  • Case C – The enabler is really big, and it can’t be implemented incrementally. The system runs when needed. In other words, do no harm.

Examples of incremental patterns are also described in [2], where the legacy subsystems are gradually ‘strangled’ over time, using proven patterns such as asset capture or event interception.

By creating the technology platforms that deliver business functionality, enablers drive better economics. But innovative product development cannot occur without risk-taking. Therefore, initial technology-related decisions cannot always be correct, which is why the Agile enterprise must be prepared to change course on occasion. In these cases, the principle of sunk costs [3] provides essential guidance: Do not consider money already spent. Incremental implementation helps, as the corrective action can be taken before the investment grows too large.

Implement Enablers Epics Across ARTs and Value Streams

Enabler epics and enabler capabilities can cut across multiple value streams or ARTs. During the analysis phase of the Kanban system, one of the important decisions to make is whether to implement the enabler in all Solution Trains/ARTs at the same time or to do so incrementally. This is a trade-off between the risk reduction of implementing one solution or system at a time versus the Cost of Delay (CoD) caused by not having the full enabler, as Figure 2 illustrates.

Figure 2. Two scenarios for implementing large enablers

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[2] Fowler, Martin. Strangler Application.

[3] Reinertsen, Donald. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

Last update: 16 October 2018