Enablers
Updated at: 31 January 2025
Enablers is a term from [SAFe methodology](), which can be translated into Russian as "auxiliary elements". Enablers refer to tasks in the product backlog that extend the capabilities of the development process. Such tasks can be represented in the backlog as epics, fiches, or user stories. Enablers provide visibility into the work required to effectively develop and implement future business requirements. They are used to explore ideas, improve the solution architecture and infrastructure, and ensure compliance with requirements. Enablers are invisible to end users, yet they are important for keeping the system up and running. Although their type is unique, they are managed similarly to customer-facing backlog elements. Enablers are treated the same as all other backlog elements - they are subject to visibility, prioritization, incremental implementation, measurement, and feedback.
## Purpose of enablers
Any supporting tasks that aim to improve the value stream can be used as enablers. According to Scaled Agile, Inc. there are four categories of Enablers by purpose:
- **Exploratory **\- support research, prototyping, and other tasks necessary to investigate customer needs, analyze alternatives, and find optimal solutions;
- **Architectural **\- ensure smooth and rapid system development within the Continuous Delivery Pipeline (CDP). Such enablers aim to maintain the system, for example, by improving performance;
- **Infrastructural **\- improve and optimize the systems used to develop, test, deploy and operate solutions;
- **Compliance** \- provide automation of audits and compliance with various regulatory, system requirements.
- **Enabler Epics** \- are created in a validated hypothesis format. Epics can span multiple Agile Release Trains (ARTs) and PIs (Program Increments) and are managed through the product backlog;
- **Enabler Features & Capabilities **\- defined within an ART and include a brief description, value hypothesis and acceptance criteria. Size should be consistent with a single PI;
- **Enabler Stories** \- articulate the user intent and what the product should do for them. Team-level tasks that should fit into a single iteration.
## Responsible persons
There are various professionals involved in working with Enablers within the SAFe methodology:
- **Architects** \- play a key role in defining and directing Enabler Epics, Enabler Features and Enabler Capabilities;
- **Agile teams** \- also use Enablers. Enabler Stories emerge locally from requirements and get into the teams' backlog;
- **Product Owners** \- participate in ART planning and system demonstrations, validating that enablers meet business goals;
- **Customers and end users** \- involved in the validation of the enablers to confirm that the solution being built meets their needs.
## Differences from other elements
While enablers are managed according to the same principles as other backlog elements (visibility, prioritization, iterative implementation, measurement and feedback), there are a number of differences:
- **A focus on solution potential rather than directly delivering value to the customer.** While conventional backlog elements focus on building functionality visible to the end user, Enablers focus on improving the architecture, infrastructure, and other capabilities needed to support future business requirements;
- **Greater impact on long-term performance.** The value of Enablers may be less obvious to end users, but their effect on system performance, scalability, and agility over the long term can be significant;
- **Closer alignment with architectural decisions**. Enablers are closely tied to architectural decisions and require architects and Agile teams to work together.
## Enablers Prioritization
Enablers require special attention in prioritization and backlog building because they provide critical, foundational technology and value stream insights, but it is important to strike a balance.
Enablers should be implemented quickly and iteratively so as not to delay the delivery of value to users. That said, large architectural and infrastructure enablers often require long, thorough development and may require a temporary system shutdown.
Therefore, it is important to consider when prioritizing enablers:
- Criticality to support future business requirements;
- Feasibility of phased implementation without stopping the system;
- Ratio of expected value to implementation costs.
A flexible approach to implementing Enablers, breaking them down into smaller iterations, and close collaboration between architects and Agile teams helps to find the optimal balance between the speed of value delivery and the required investment in the technology foundation.
## A simple example of using Enablers in an IT project
A team develops a mobile application for personal finance management, one of the functions of which is synchronization of data between user devices.
In the course of work, the team realizes that they need a new server architecture to implement reliable and efficient synchronization. The current architecture cannot handle the load and does not provide the proper level of security. To address this challenge, the team defines the following list of enablers:
**Enabler Epic**
*"Create a scalable and secure server architecture for data synchronization"*
- Defines the overall goals and hypotheses for this architectural enhancement;
- is driven by architects who provide visibility and prioritization across the portfolio.
**Enabler Features**
1. *High-performance caching system;*
2. *Data encryption and authentication;*
3. *Distributed data storage.*
- Define the specific architectural components required to implement epic;
- are managed by architects in conjunction with development teams.
**Enabler Stories**
*"As a systems engineer, I want to tune the horizontal scaling of a Redis cluster to ensure high caching performance"*
*"As a security engineer, I want to integrate AWS KMS to encrypt user data in flight and storage"*
*"As a DevOps engineer, I want to automate the deployment and monitoring of a Cassandra-based distributed data warehouse"*
- Define specific requirements of specialists to realize architectural capabilities;
- are managed by development, DevOps, and systems engineering teams.
The described enablers do not directly benefit users, but provide a solid technological foundation for further application development.