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
Features and Capabilities
A Feature represents solution functionality that delivers business value, fulfills a stakeholder need, and is sized to be delivered by an Agile Release Train within a PI.
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 PI.A Capability represents large solution functionality whose implementation often spans multiple ARTs and is sized to be delivered within a 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.
Details
Features and capabilities are critical to defining, planning, and implementing Solution value. Figure 1 provides a broader context for these work items:
Figure 1 shows that solutions are developed using features. Each reflects a service provided by the system that fulfills some important stakeholder needs. They are maintained in the ART Backlog and sized to fit in a PI so that each delivers new value. Features can originate from either the Agile Release Train (ART)’s local context or from splitting Epics or capabilities.
The ART and Solution Train Kanban systems support the flow of features and capabilities, where they progress through the funnel, analyzing, backlog, implementing, validating, deploying, and releasing states. This process provides reasoned economic analysis, technical impact, and strategy for incremental implementation.
Product Management and System Architect define 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 system’s design across the different backlogs. Features are prioritized using Weighted Shortest Job First (WSJF) and are planned and reviewed at PI boundaries. They are split into Stories and are implemented, integrated, tested, and demonstrated as the functionality becomes available.
Discovering and Describing Features
Design Thinking takes a Customer-Centric approach to creating desirable and sustainable products. Design thinking tools, including personas, empathy maps, and customer journey maps, provide empathy towards and a deeper understanding of customers and users. Together, they offer a rich context to better understand features and their potential benefits.
Features are defined using a features and benefits format:
- Feature – A short phrase giving a name and context
- Benefit hypothesis – The proposed measurable benefit to the end user or business
Avoid defining features with the ‘user story voice’ format designed to support one user role; features typically provide functionality for multiple user roles. Furthermore, using the same method to describe user stories and features may cause confusion.
Figure 2 illustrates an example set of features with benefits hypotheses:
Creating and Managing Features
In collaboration with Product Owners and other key stakeholders, Product Managers define features in the local context of an ART. Some arise as a result of splitting epics.
System Architects typically create enabler features. The ART backlog is used to maintain enablers alongside business features. Enablers pave the Architectural Runway and support exploration or provide the infrastructure needed to develop, test, and integrate the solution.
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 ART backlog to ensure enough emphasis on furthering the solution and extending the architectural runway. At each PI boundary, the percentage of resources allocated to new features (or capabilities) versus enablers is estimated to guide the train.
Prioritizing Features
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 overstate the importance of this critical process.
Product and Solution Management use WSJF to prioritize features, while System and Solution Architects also use WSJF to prioritize enabler features. Since business features and enabler features exist in the same backlog, Product and Solution Management must work collaboratively with System and Solution Architects to reconcile differences in priorities. Aligning priorities to Strategic Themes and capacity allocation are two approaches to creating alignment and balance in the backlog.
Estimating Features
Feature estimation supports forecasting value delivery, applying WSJF prioritization, and sizing epics by splitting them into features and summing their estimates. Feature estimation usually occurs in the analysis state of the ART Kanban. It relies on normalized estimation techniques, similar to the methods used by Agile teams (see the Iteration Planning article for more detail). During analysis, select subject matter experts from the ART engage in exploration activities and preliminary sizing.
Accepting Features
Feature acceptance criteria determine whether the implementation is correct and delivers the business benefits. Figure 3 provides an example:
Acceptance criteria mitigate implementation risk and enable early validation of the benefit hypothesis by creating alignment between product management, stakeholders, and developers. Acceptance criteria can also be used as the source of stories. As with stories, acceptance criteria are often transformed into acceptance tests with Behavior-Driven Development (BDD).
Product Management is responsible for accepting the features. They use acceptance criteria to determine whether the functionality is implemented correctly and whether nonfunctional requirements are met.
Capabilities
Most of this article is devoted to describing the definition and implementation of features, as they are the most common description of system behavior. Capabilities exhibit the same characteristics and practices as features. For example, they:
- Are described using a phrase and benefit hypothesis
- Are sized to fit within a PI; however, they often take multiple ARTs to implement
- Are reasoned about and approved using the Solution Train Kanban. The Solution Train Backlog holds approved capabilities
- Have associated enablers to describe and bring visibility to all the technical work necessary to support the efficient development and delivery of business capabilities
- 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 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 aspects of the environment may require additional solution functionality.
Splitting Features and Capabilities
Capabilities must be decomposed into features to be implemented. They, in turn, are split into stories consumable by teams within an iteration. SAFe provides ten 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.
Last update: 14 December 2022