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.
Features and Capabilities
A Feature is a system service that fulfills a stakeholder need. Each feature includes a Benefit Hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI).
A Capability is a higher-level solution behavior that typically spans multiple ARTs. Capabilities are sized and split into multiple features so that they can be implemented in a single PI.
SAFe describes a hierarchy of artifacts that define functional system behavior: Epics > capabilities > features > Stories. This article describes features and capabilities, which are used to define system and Solution behavior.
Features and capabilities are developed and managed through the Program and Solution Kanban systems, respectively, where they progress through the funnel, analyzing, backlog, implementing, validating, deployment, and release states. This process provides reasoned economic analysis, technical impact, and strategy for incremental implementation.
Features also lend themselves to the Lean User Experience (UX) process model, which includes a definition of the Minimum Marketable Feature (MMF), a benefit hypothesis, and acceptance criteria. This helps limit scope and investment, enhances agility, and provides fast feedback about the benefit.
Capabilities behave the same way. They are simply a level of abstraction above features, applied to building Large Solutions.
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.
As Figure 1 shows, features are the 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 new feature 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 (WSJF ). They realize value in the context of certain Nonfunctional Requirements (NFRs). Features are planned and reviewed at PI boundaries and 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.
Features are described using a Features and Benefits (FAB) Matrix:
- Feature – A short phrase giving a name and context
- Benefit hypothesis – The proposed measurable benefit to the end user or business
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.
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 and 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.
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.
Feature estimation facilitates forecasting value delivery, applying WSJF prioritization, and sizing larger initiatives such as epics. Feature estimation usually occurs in the analyzing 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 estimating). 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 preliminary sizing.
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:
Acceptance criteria mitigate implementation risks but also provide early validation of whether or not the feature will provide the value in the benefit hypothesis. 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.
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. Capabilities exhibit the same characteristics and practices as features. For example, capabilities:
- Are described using a phrase and benefit hypothesis.
- Originate in the local large solution level context or are derived from epics.
- Are sized to fit in a PI.
- Are reasoned about and approved using the Solution Kanban. Approved capabilities are maintained in the Solution 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 , chapter 6. They can be applied to all the above-mentioned cases.
- Workflow steps
- Business rule variations
- Major effort
- Variations in data
- Data methods
- Deferring system qualities
- Use-case scenarios
- Breaking out a spike
An example of splitting a capability into features is illustrated in Figure 4.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last update: 1 October, 2017