Change is the principal feature of our age.

David Brin

Feature Abstract

Features are services provided by the system that fulfill one or more stakeholder needs. They are maintained in the Program Backlog and are sized to fit in PSI/Releases so that each PSI/Releases delivers conceptual integrity (it all works together; there are no big holes for the user to fall into). Because of this, each PSI/Release can be safely delivered to the business or market (or not) based on the current business conditions. In SAFe, features bridge the gap between User Stories (which are sized to fit in iterations) and Epics (which span PSII/Releases).

The term feature is not unique to SAFe—we simply leveraged industry-standard nomenclature whereby product managers, marketing, and sales personnel typically describe products to customers in terms of the features it offers and the benefits each provides (often called the Feature and Benefit, or FAB, matrix).

Features are estimated, sized, and split as necessary to fit within a PSI/Release. The appropriate and judicious selection of features drives the primary economic benefit. The lean economic algorithm of weighted shortest job first (WSJF)   is used to prioritize features.This is done routinely and at every PSI/Release boundary. This creates a continuous, rolling-wave prioritization mechanism that drives the optimal sequence of feature delivery, which in turn provides the optimal economic returns for the program.


Features are a central part of the Scaled Agile Framework Enterprise Backlog Model (Epics>Features>Stories)  and often come from the breakdown of Epics, which are the large, customer-facing initiatives which realize the benefits of  Investment Themes).  Features live at a level above specific requirements and bridge the gap from the problem domain (understanding the needs of the users and stakeholders) to the solution domain (specific requirements and acceptance criteria), which we express as user stories in Agile.

The Attributes of a Feature

Though features can be described in user voice format, and there can be some value in that, we don’t necessarily recommend it, mostly because Product Managers haven’t been taught that way, and features can then be so easily  confused with User Stories, which are at a much lower level of abstraction.  Instead, we recommend a simpler, traditional approach, which is immediately familiar to Product Managers: a Features and Benefits Matrix, or “FAB.” An example appears in Figure 1.

Figure 1. Ping Identity Features and Benefits matrix. (Provided courtesy of Ping Identity)

As can be seen in the FAB in Figure 1, the attributes of a feature may include:

  • The Feature A short 1 – 3 word title summarizing the feature
  • The Benefit – A short description which elaborates the feature and describes the value to the user.  There may be multiple benefits per feature

In addition to features and benefits, we specify other attributes as we elaborate:

  • Weighted Shortest Job First (WSJF) is the economic prioritization algorithm for job sequencing based on relative value and job size.  WSJF has a time element which, (assuming the team’s backlogs estimates contain only the work remaining for a feature) automatically ignores sunk costs, which is a key tenet of lean economics. It’s especially suited for rolling wave planning and feature re-prioritization at PSI/Release boundaries, since periodic re-prioritizing addresses the time element in WSJF.
  • Acceptance criteria – As with user stories, the acceptance criteria specify when the feature can be considered to be complete.

Once a feature is selected for implementation, it will be broken down into specific user stores, and potentially described further via system level use cases, UI frames, and other artifacts.

Estimating Effort

In order to sequence features using WSJF, the job size (effort) is estimated using relative sizing. Depending on its state of elaboration in the Program Backlog (as well as how important it is to have refined estimates), the estimate for a feature may go through three stages: preliminary, refined, and final.

  1. Preliminary (Gross, Relative Estimating) – In this stage, product management may simply need a rough, gross estimate before it goes to the teams for discussion.  The feature doesn’t require an estimate in story points.  Instead, a simple relative estimating model can be used in which the “bigness” of one feature is compared to another.  Depending on complexity of design, implementation, and testing, the feature may be estimated only be product management, or may include representatives from system architecture, development, and the teams.
  2. Refined (Estimates in Story Points) – In this stage, estimates are done in story points.  Specifying this level of refinement can most easily be done when there is historical data and new features can be compared to similar features.  The team(s) are often brought in at this point for discussion, though this form of refinement should be done on a cadence to minimize disruptions to the team.
  3. Final (Bottom-up, Team Based Estimating) – When the fidelity of an estimate needs to be improved, such as at a PSII/Release boundary or Release Planning Meeting, the teams do the estimate using a bottom-up approach by breaking the feature down into stories and estimating the stories.

Splitting Features

Splitting features to fit within a PSI and implementing them incrementally is both an art and a science, and is a necessaryskill  for implementing Agility at enterprise scale.  Techniques used to split stories can also be applied to features as well.  Table 2 shows ten patterns for splitting stories as described in Ref [1, Chapter 6: User Stories].

Figure 2 Ten Possible Ways to Split User Stories

Features Implemented by Multiple Teams

Ideally, a feature can be built by a single agile team.  However, in large enterprise systems, teams may be Feature teams or Component teams,  and hybrids of both. (Yes, of course, we support the need and drive to build more feature teams than component teams, but in the meantime, you have what you have). In this case, some coordination is required to build a larger value feature. For example, one team may build the data access layer while another builds the user interface. The bigger and more valuable the feature, the more teams are likely involved.

In such a case, a feature will have multiple inputs, which must be implemented in order to be delivered.  Each team breaks down its portion of the feature into user stories and estimates their portion of the work.  The estimates from all teams are then aggregated into a full feature estimate.

(Note: While the user of a feature is a business-facing customer, the user of a component team’s stories may be another component team or a feature team.  In lean, the customer is anyone who consumes your work. And remember “don’t trouble your customer”.)

The Top Ten Features in Release Planning

Features are used to express the Vision presented by product management in the Release Planning Meeting.  To minimize work in process (WIP), product managers typically present the top 10 features per solution domain.  During release planning, final bottom-up estimating takes place, features are split as needed, and scope may be negotiated.  If the feature cannot be split and scoped to fit within the PSI, it will remain in the program backlog and re-evaluated before the next release planning meeting.

Learn More

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

 Last update: 21 February, 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact