Component Teams vs. Feature Teams

Infographic showing the comparison of Component and feature teams

The Scrum framework doesn’t specify whether a Scrum Team is a feature or a component team. Only that we have a done integrated tested increment at least once per sprint. It’s important to understand the difference between these constructs and their advantages and disadvantages. There are a few disadvantages to Component Teams that can prevent organisations gaining greater agility. Let’s take a look.

Component Teams are:

  • Teams organized for technical layers or technical components.
  • Many teams needed to turn a customer-centric feature on Product Backlog into a releasable Increment
  • Horizontal slicing; work is divided by technical layer or technical components.
  • Teams are only together for the duration of the program-project lifecycle. May be involved in multiple projects.
  • Lots of coordination needed to integrate an potentially releasable increment.
  • Very difficult to understand where we are. Lack of transparency
  • Requires project management

Feature Teams are:

  • Long lived, work on many features together over time.
  • Cross-discipline, cross-component. Each feature team has all skills to turn Product Backlog into releasable Increments.
  • Vertical slicing; work is divided by end-user functionality.
  • Work is integrated continuously within each Sprint.
  • Transparency ensured; no unknown, undone work. Potentially releasable increment at least once per sprint

Some or all of the following behaviours will be observed with Component Teams

Although sometimes necessary make them the exception rather than the rule.

  • Leads towards or reinforces waterfall process and holds back breaking down of organisation silos like Business Change, Architecture, Development, Test, Ops
  • Leads to water-scrum-fall, scrumer-fall. Something that uses the language of Scrum but definitely isn’t Scrum
  • Release of value is delayed, validation delayed
  • Lack of end-to-end accountability for the customer leads to lack of creativity and self-organisation. Kills intrinsic motivation
  • Increased risk
  • Facilitates big up front design
  • Delays learning, delayed functional and non-functional testing
  • Increased hand off waste and delays
  • Project task switching impacts work and morale
  • High technical debt

Some or all of the following behaviours will be observed with Feature Teams

  • Leads to customer and business focused organisations
  • Leads to iterative and increment release of value and validation
  • Maximised value
  • End-to-end accountability
  • Facilitates emergent design
  • Encourages creativity, intrinsic motivation
  • Enables self organisation
  • Shared code ownership promotes good engineering practices clean code, CI, CD, refactoring, automation, testing. Higher quality = lower cost of ownership
  • Decreased risk. Deal with high risk items and deploy to production
  • Ensures transparency
  • Flexibility and Stability.
  • Can focus on the flow of value
  • Can learn from each other and cross skill

Let's stay connected

Simply fill in the form below and be the first to find out our latest news, offers and advice.

  • This field is for validation purposes and should be left unchanged.

By completing this form you are agreeing to our privacy policy