There’s innovation in Linux. There are some really good technical features that I’m proud of. There are capabilities in Linux that aren’t in other operating systems.

—Linus Torvalds

Features and Capabilities Abstract

SAFe describes a hierarchy of artifacts that describe functional system behavior: Epics>Capabilities>Features>Stories. This article describes Features and Capabilities, which are used to describe system and Solution behavior.

The terms features and capabilities are not unique to SAFe. They are largely industry-standard terms, used by Product and Solution Managers, chief engineers, marketing, and sales personnel to describe products and solutions to Customers. A feature is a service provided by the system that addresses one or more user needs. A capability describes the higher-level behaviors of a solution at the Value Stream Level.

Features and capabilities are developed and managed through the Program and Value Stream Kanbans, respectively, where they progress to facilitate readiness, prioritization, and approval, and await implementation. This process assumes reasoned economic analysis, technical impact, and strategies for incremental implementation.

To avoid redundancy, most of this article is devoted to describing the definition, articulation, and implementation of features, as they provide the description of system behavior for each ART. Capabilities are simply a level of abstraction above features, applied to the solution in the optional value stream level, where they exhibit largely the same attributes.


Features and Capabilities are central to the SAFe Requirements Model. They are critical to definition, planning, and implementation of value and represent the most basic mechanism of advancing the Solution in SAFe. Figure 1 provides the larger context for these artifacts.

Figure 1. Feature in context of SAFe
Figure 1. Feature in context of SAFe

As Figure 1 shows, features are the required, primary, functional system definition element. Each feature reflects a service provided by the system that fulfills some stakeholder need. Features are maintained in the Program Backlog and sized to fit in Program Increments, so that each PI delivers value. Features originate from the local context of the Agile Release Train, or they may arise as a result of splitting Epics or capabilities.

Features (and, similarly, capabilities) are managed in the Kanban systems. They are subject to Product Management and System Architect/Engineering authority and prioritized using Weighted Shortest Job First, or WSJF. They realize value in the context of certain Nonfunctional Requirements. Features are planned and reviewed at PI boundaries; implemented as Stories; and are integrated, tested, and demonstrated as the functionality becomes available.

Capabilities are similar to features; however, they describe higher-level solution behaviors and often take multiple ARTs to implement. Capabilities are sized to fit within PIs to ensure that each PI delivers incremental and measurable value. (Epics are used to describe initiatives that require multiple PIs to implement.) Capabilities may originate in the local context of the solution or occur as a result of splitting portfolio epics that may cut across more than one Value Stream. Another potential source of capabilities is the Solution Context, where some aspect of the environment may require new solution functionality.

Describing Features

Features are described using a Features and Benefits Matrix (FAB).

  • Feature – A short phrase giving a name and some implied context
  • Benefit – A short description of the benefit to the user and the business; there may be multiple benefits per feature

Since features can span multiple user roles, SAFe generally recommends against using the user story voice to express them. Furthermore, the business is not usually familiar with user stories and it may cause confusion if the same format is used for both stories and features.

An example features and benefits matrix is illustrated in Figure 2.

Figure 2. Network router features and benefits matrix example
Figure 2. Network router features and benefits matrix example

Creating and Managing Features

In collaboration with Product Owners and other key stakeholders, features are created by Product Managers in the local context of an ART. Others arise as a result of decomposition of epics. Enabler features pave the Architectural Runway, support exploration, or may provide the infrastructure needed to develop, test, and integrate the initiative. Enabler features are generally created by Architects or Engineers and maintained in the program backlog alongside business features.

Just like business features, enabler features may originate from epics or emerge locally at the ART level in support of the needs of the Agile Teams, ARTs, or value streams. Enablers that make it through the Kanban systems will be subject to capacity allocation in the program backlog to ensure that enough emphasis is placed on both, furthering the solution and extending the architectural runway. Capacity allocation can be applied for enabler work as a whole or it can be used to differentiate between the various types of enablers.

Prioritizing Features

SAFe applies WSJF for continuous prioritization of features in the program backlog. Since selecting the right work items in the right sequence delivers the primary economic benefit to the ART—and thereby the solution—it’s hard to overestimate the importance of this critical process.

Estimating Features

Features estimation facilitates forecasting value delivery, applying WSJF prioritization, and sizing larger initiatives such as epics. Feature estimation usually occurs in the “refinement” state of Program Kanban and relies on normalized estimation techniques, equivalent to the approach used by Agile Teams for estimating stories (see the Stories article for more detail on estimating with normalized story points). Feature estimation at this point, however, does not require full breakdown into stories or involve all the teams that possibly will be involved in feature development. Instead, select subject matter experts may be involved in basic exploration and sizing.

Accepting Features

Features also have acceptance criteria that are used to determine whether the implementation is correct and delivers the business benefits. Figure 3 provides an example of a feature with acceptance criteria:

Figure 3. Feature acceptance criteria example
Figure 3. Feature acceptance criteria example

Elaboration of acceptance criteria not only mitigates implementation risks but also provides early validation of whether or not feature scope entails desirable value to the business. In addition, acceptance criteria are typically the source of various stories, as well as functional tests, that are developed and automated to support refactoring and regression testing.

Product Management is responsible for accepting the features. They use acceptance criteria to determine whether the functionality has been properly implemented and nonfunctional requirements met.

Value Stream Capabilities

Most of this article is devoted to describing the definition, articulation, and implementation of features, as they are the most prevalent description of system behavior. Since capabilities are aggregations of features at the solution level, they exhibit the same characteristics and practices. For example, capabilities:

  • Are described using a similar matrix as the feature and benefits matrix and have associated acceptance criteria
  • Originate in the local value stream context or are derived from epics
  • Are sized to fit in a PI
  • Are reasoned about and approved using the Value Stream Kanban. Approved capabilities are maintained in the value stream backlog
  • Have associated enablers to describe and bring visibility to all the technical work necessary to support efficient development and delivery of business capabilities
  • Are accepted by Solution Managers, who use the acceptance criteria to determine whether the functionality has been properly implemented.

Splitting Features and Capabilities

Capabilities must be split into features to be implemented. Features, in turn, are split into stories consumable by teams within an iteration timebox. The list below provides 10 patterns for “splitting work,” as described in Leffingwell [1, Chapter 6]. They can be applied to all the above-mentioned cases.

  1. Work flow steps
  2. Business rule variations
  3. Major effort
  4. Simple/complex
  5. Variations in data
  6. Data methods
  7. Deferring system qualities
  8. Operations
  9. Use-case scenarios
  10. Breaking out a spike

An example of splitting a capability into features is illustrated in Figure 4.

Figure 4. A capability split into features
Figure 4. A capability split into features


Learn More

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

Last update: 21 April 2016