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, creator of Linux
A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria and is sized or split as necessary so that it can 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 to facilitate their implementation in a single PI.
Features also lend themselves to the Lean UX process model, which includes a definition of the Minimum Marketable Feature (MMF), a benefit hypothesis, and acceptance criteria. The MMF helps limit the scope and investment, enhances agility, and provides fast feedback. Capabilities behave the same way as features. However, they are at a higher level of abstraction and support the definition and development of large Solutions.
Features and capabilities are central to the SAFe Requirements Model. They are critical to defining, planning, and implementing Solution value. Figure 1 provides the broader context for these work items.
As shown in Figure 1, solutions are developed using features. Each reflects a service provided by the system that fulfills some important stakeholder need. The features are maintained in the Program Backlog and are sized to fit in a PI so that each delivers new value. Features can originate either from the local context of the ART or from splitting Epics or capabilities.
The Program and Solution Kanban systems support the flow of features and capabilities, 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.
Product Management and System Architect/Engineering own the features and enablers, respectively. Nonfunctional Requirements (NFRs) define system attributes such as security, reliability, performance, maintainability, scalability, and usability. NFRs serve as constraints or restrictions on the design of the system across the different backlogs. Features are prioritized using the Weighted Shortest Job First (WSJF) method and are planned and reviewed at PI boundaries. They are split into Stories, and are implemented, integrated, tested, and demoed as the functionality becomes available.
Features are defined 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
It’s best to avoid defining features with the ‘user story voice’ format that is designed to support one user role, because features typically provide functionality for multiple user roles. Furthermore, using the same method to describe user stories and features may confuse the Business Owners, since they are not usually familiar with stories.
Figure 2 illustrates an example FAB matrix with four different features.
Product Managers, in collaboration with Product Owners and other key stakeholders, define features in the local context of an ART. Some of these features may arise as a result of splitting epics.
System Architects typically create enabler features, which are then maintained in the program backlog alongside the business features. Enablers may pave the Architectural Runway and support exploration, or they may provide the infrastructure needed to develop, test, and integrate the initiative.
Just like business features, enabler features may originate from epics or emerge locally at the ART level. Enablers that make it through the Kanban system will be subject to capacity allocation in the program backlog to ensure that enough emphasis is placed on both delivering the solution and extending the architectural runway. At each PI boundary, the percentage of resources to be allocated to new features (or capabilities) versus enablers is estimated to guide the train.
The WSJF prioritization model is used to sequence jobs (e.g., features, capabilities) based on the economics of product development flow. Since implementing the right jobs in the right sequence produces the maximum economic benefit, it is hard to overestimate the importance of this critical process.
Product and Solution Management have authority to prioritize features, while System and Solution Architects and Engineering have authority to prioritize enabler features.
Feature estimation supports forecasting value delivery, applying WSJF prioritization, and sizing epics by splitting them into features and summing their individual estimates. This process usually occurs within the analysis state of the Program Kanban and relies on normalized estimation techniques, similar to the methods used by Agile teams (see the Iteration Planning chapter for more detail). During analysis, subject-matter experts from the ART engage in exploration activities and preliminary sizing. While in this state, sizing of features does not require splitting them into stories or including all the teams that might develop them.
Acceptance criteria are used to determine whether the implementation is correct and delivers the business benefits. Figure 3 provides an example.
Acceptance criteria are intended to mitigate implementation risks and enable early validation of the benefit hypothesis. Moreover, acceptance criteria are typically the source of various stories as well as functional tests, which are developed and automated to support refactoring and regression testing.
Product Management is responsible for accepting the features. These managers use acceptance criteria to determine whether the functionality is properly implemented and the nonfunctional requirements are met.
Most of this chapter is devoted to describing the definition and implementation of features, as they are the most commonly encountered descriptions of system behavior. Capabilities exhibit the same characteristics and practices as features:
Capabilities are described using a phrase and benefit hypothesis.
They are sized to fit within a PI, although they often take multiple ARTs to implement.
They are reasoned about and approved using the Solution Kanban. The Solution Backlog holds approved capabilities.
Capabilities have associated enablers to describe and bring visibility to all the technical work necessary to support efficient development and delivery of business capabilities.
They are accepted by Solution Managers, who use the acceptance criteria to determine whether the functionality is fit for purpose.
Capabilities may originate in the local context of the solution or arise from splitting of 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.
Capabilities must be decomposed into features to be implemented. These features, in turn, are split into stories that can be handled by teams within an iteration. SAFe provides 10 patterns for splitting work, as described in Leffingwell [1], Chapter 6.
Workflow steps
Business rule variations
Major effort
Simple/complex
Variations in data
Data methods
Deferring system qualities
Operations
Use-case scenarios
Breaking out a spike
Figure 4 illustrates splitting a capability into features.
LEARN MORE
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
