Innovation comes from the producer, not the customer.
—W. Edwards Deming

Features and Components

Features and Components embodies two key abstractions we use to build software and systems:

  • Features are those behaviors of the system that directly fulfill some user need
  • Components are distinguishable system parts that provide and encapsulate common functions needed to implement features

Agile’s value delivery focus emphasizes features (and constituent stories) that solve user needs and differentiate solutions. However, resilient large-scale systems are built out of components that provide for separation of concerns, foster logic re-use, and improved testability. These provide a foundation for fast system evolution.

Both abstractions exist may be commonly recognized. Particularly in enterprise Agility there can be some interesting discussions about how to organize teams – around features, components, or some mix of both. Getting the organization right drives innovation on scalable systems that can grow as your knowledge grows. Getting it wrong leads to either

  • Brittle systems that are unmaintainable and rapidly obsolescent (all features, all the time)


  • Brilliantly designed systems with inherent future user value to keep the enterprise competitive (all components, all the time)

This article describes these abstractions in the context of large-scale agile systems development, and provides some organizational guidance to continually evolve the agile organization to optimize velocity and accelerate value delivery.


Components and Features

The architecture of a software system can be described, in part, in terms of its component structure, and its Features. The components interact to deliver the consistent user-facing behaviors that constitute the Features. Teams build systems out of components to provide scalability, flexibility, common functions re-use, and maintainability.

The creation of a specific component can be driven by a number of motivations:

  • Implementation/isolation of a specific technology (example: PHP-based UI, Java-based business logic)
  • Re-use of logic (example: transaction processing module)
  • Protective isolation for purposes of controlling security, compliance, safety, etc.
  • To support an anticipated high rate of changing requirements (ex: bridge/adapter modules, proxy objects, etc.)

The word ‘component’ is a pretty broad term; in SAFe it can refer to any of the following:

  • A system layer (such as UI, Application or Data layer)
  • A software module or package
  • An application library
  • A subsystem

Component Teams

A component team is a Define-Build-Test Team whose primary area of concern is restricted to a specific component, or set of components, of the system. Accordingly, the team backlog typically consists of Technical Stories (as opposed to User Stories), as well as Refactors and Spikes. It can make sense to create a component team when a component:

  • Can be used by other entities, business units, or subsystems
  • Would otherwise appear in many places in the codebase, complicating maintenance and testability
  • Can be uniquely responsible for functionality related to compliance, safety, security, or regulation
  • Contains unique or legacy technology
  • Provides algorithms or logic that require specific, deep technical and/or theoretical expertise
  • Operates on large data sets, performs highly intensive computations, and/or has to satisfy some critical nonfunctional requirements, such as availability or throughput.

Prior to Agile, most large-scale systems development programs were typically already organized around components and subsystems (the old mantra: organization follows architecture). Therefore in an Agile transformation, sometimes the simplest first step to create Agile Teams that follow the existing, component-based organizational pattern, as Figure 1 illustrates.

Figure 1. An Agile program comprised of component teams

Feature Teams

The disadvantages to the above are obvious: most new features create dependencies that require cooperation between these teams. This is a continuing drag on velocity, as the teams spend much of their time discussing dependencies between teams and testing behavior across components rather than being able to deliver end user value. And we certainly don’t need components or component teams when:

  • Most new user stories require unique changes to specific parts of the code base
  • The code of interest has no higher criticality than any other component in the system
  • The code does not require unique, rare, or different skills and technologies
  • The code will be not heavily used by other code, components or systems

In these cases, it is best to create feature teams that are organized around user-centered functionality. Each team, or small team of teams, is capable of delivering end-to-end user value as Figure 2 illustrates. Feature teams operate primarily with user stories, refactors and spikes. However, technical stories may also occasionally occur in their backlog.

Figure 2. An example of feature teams

Even then, though they are called feature teams, it is not always true that such a team can complete a feature by itself. Features can be too big to be consumed by one Agile team and are split up into multiple user stories. These are, in turn, implemented by other feature teams. In addition, the very notion of a feature OR component team is a bit simplistic, as many effective teams have responsibility for a number of both. However, in summary:

To ensure highest feature throughput, SAFe generally recommends a mix of perhaps 75-80% feature teams and 20-25% component teams.

Given that a mix is most likely appropriate, two main factors drive it:

  • The practical limitation of the degree of specialization required
  • The economics of potential reuse.

Figure 3 illustrates these parameters and a curve that can be used to decide the choice of one over another.

Figure 3. The feature and component teams power curve

This “mixed model” emphasizes additional capabilities needed to drive program velocity:

  • System level, Continuous Integration (CI) infrastructure: Feature teams must to be able to integrate the entire system at any desirable point.
  • Test automation: Broad, automated regression test suites must be built and available as well.
  • A special team, the System Team is engaged in actively improving and supporting the CI systems and processes used by the feature and component teams
  • Communities of Practice can be organized to share component-related knowledge across feature teams
  • And, of course, a strong emphasis on endemic code quality, along with refactoring skills, is mandatory for scaling


This article describes the minor conundrum of organizing Agile programs around feature teams vs. component teams. Evolution to a mix, biased towards feature teams, appears to produce the highest velocity and efficacy of larger-scale Agile development. Simply, dependencies are fewer and easier to manage, and value throughout is higher with feature teams. Even then, we recognize that these words are both abstractions, and one person’s feature may be another’s component. To that end, Agile programs must continually inspect and adapt, and indeed reorganize, as necessary to follow the value that is driving the market.

Learn More


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

Last update: January 15, 2013

Leffingwell et al. © 2011-2014 Scaled Agile, Inc.