Change is the principal feature of our age.

David Brin

Feature Abstract

Features are services provided by the system that fulfill stakeholder needs. They are maintained in the Program Backlog and are sized to fit in a Program Increment so that each PI delivers conceptual integrity: it all works together to deliver integral user value. Features lie between user stories, which are sized to fit in iteration, and epics, which typically span PIs and releases. Features are prioritized by weighted shortest job first (WSJF), which is updated at each PI boundary. This continuous, rolling-wave prioritization mechanism drives the optimal sequence of feature delivery, which in turn provides the optimal economic returns for the Agile Release Train.

Details

The term “feature” is not unique to SAFe—it is 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. Features are central to the SAFe Backlog Model (Epics>Features>Stories). Features bridge the gap from the problem domain (understanding the needs of the users and stakeholders) to the solution domain (specific system behaviors designed to meet those needs). Features are held in the Program Backlog, until time for implementation. Most arise locally at the Program Level, based upon the needs of the users. Others come from the breakdown of Portfolio and Program Epics.

Features and Benefits

Though features can be described in user voice format, we don’t generally 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. An example Features and Benefits matrix. (Provided courtesy of Ping Identity)

As can be seen in Figure 1, features are described with two aspects:

  • Feature – A short phrase, giving a name and some implied context to the feature
  • Benefit – A short description which describes the benefit to the user and the business.  There may be multiple benefits per feature which are highlighted here

Prioritizing Features

SAFe applies Weighted Shortest Job First (WSJF) for continuous prioritization of features in the program backlog.  Since selecting the right jobs (features) in the right sequence (time) delivers the primary economic benefit to the Agile Release Train—and thereby the Value Stream and portfolio—it’s hard to underestimate the importance of this critical process. Simply, programs that do this well will outperform others in the marketplace.

The numerator of WSJF is Cost of Delay, which in the SAFe context, combines user/business value, time value and risk reduction/opportunity value into one number. Since there are a variety of backlog items to choose from, each of these parameters can be estimated fairly quickly by simply comparing the subject feature to other features in the backlog.  Since WSJF has a time element (time value), it is especially well suited for flow-based, just-in-time, rolling-wave planning and feature re-prioritization at PI boundaries. (Note: The denominator of WSJF is job duration, and we’ll look at the critical parameter in the section below.)

In addition, applying capacity allocation to the program backlog helps separate the technical versus business concerns, so that each are addressed in accordance with the current business needs. By this process, product management is chartered with continuous development, update, refinement and prioritization of the program backlog, and they thereby steer the train towards delivery of maximum economic value.

Estimating Feature Size

Proper economic prioritization requires an understanding of job size. After all, you can’t understand the comparative return on investment of a new thing without knowing what it might cost to do that thing.  Picking the right, next-best feature is the art of the ART, and estimating job size is a key skill to that end. Depending on the level of understanding that is required for proper economics, the estimate for a feature may go through three stages: a Preliminary Relative Estimate, a Gross Absolute Estimate, and a Derived Absolute Estimate. Each can serve as a proxy (in a system of fixed capacity, duration depends on job size) for the denominator in WSJF, as follows:

  1. Preliminary Relative Estimate – In some cases, product management may simply need an initial, rough estimate. After all, they have plenty of features to choose from. At this level of understanding, relative estimating can be used to compare the “bigness” of one feature to another.  Depending on complexity of design, implementation, and testing, the feature may be estimated only by product management, or more typically include input from system architecture and development.
  2. Gross Absolute Estimate – The relative estimating scheme above is fast and straightforward, but the increasing range in the relative Fibonacci numbers can leave some pretty big uncertainty in the prioritization. To take the next step in fidelity, or perhaps to get a quick estimate of potential cost, those responsible can also use historical comparisons, established by comparing the new feature size to the story points required to deliver comparable features in prior periods.
  3. Derived Absolute Estimate – Finally, when the fidelity of an estimate needs to be further improved,  the teams can break the feature down into stories, and estimate the individual stories. The sums of those estimates by the teams involved, creates the most refined estimate of potential scope and cost.

Each of these mechanisms provides an estimate of job size, which is a decent proxy for duration and prioritization under WSJF. (Note: If size is not a good proxy, due the the availability of flexible or more extensive resources, then adjust for duration accordingly). The latter two mechanisms also provide an estimate of cost, since moving from story points to cost is pretty straightforward when teams apply normalized estimating.

Feature Acceptance Criteria

Features also have associated acceptance criteria, which are used to determine that the implementation of the feature is correct and that it should therefore deliver the business benefits. An example Feature, Benefit and Acceptance criteria for a user login function appears in the example below.

Feature: Multi-factor Authentication
Benefit: Enhanced security for user authentication with both a password and a physical device
Acceptance Criteria:
1. USB tokens as a first layer
2. Password authentication second layer
3. Support multiple tokens on a single device
4. User activity log reflects both authentication factors

Elaboration of acceptance criteria helps assure that there is a manageable risk that the Feature can be implemented within a PI. In addition, acceptance criteria are typically the source of various user stories as well as functional tests, which are developed and automated to support future refactoring and regression testing.

Splitting Features

Features often must be split to fit within a PI.  Techniques used to split stories can also be applied to features as well.  The list below shows ten patterns for splitting as described in [Ref 1, Chapter 6: User Stories].

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

Features Implemented by Multiple Teams

Ideally, a feature can be built by a single agile team, and the ART organization will rapidly evolve to that end.   However, in large systems, there will typically be both Feature teams and Component teams, and hybrids.  And in many cases,  a feature is too large to be implemented by a single team, and some coordination is required.  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.  When it comes to estimating, 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.

The “Top Ten” Features in Release Planning

Features and benefits are used to express the Vision presented by product management in Release Planning.  To limit WIP to a near-term PI focus, product managers typically present only the top 10 features to the teams.  During release planning, features are split as needed and stories are developed to implement the feature; scope may be negotiated.  If the feature cannot be split and scoped to fit within the PI, 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: 22 July, 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 permissions@ScaledAgile.com.