Feature teams vs Component teams

Last post 11:40 am December 5, 2018
by Sander Dur
4 replies
08:25 pm November 25, 2018


I'm trying to make sure I understand what a feature team is. Currently, we are organised by our skillset. That is - 

- Operations team that carry out support work (i.e. respond to tickets)

- Reporting team who specialise in reporting tookits

- Developers

- Architects

So there are four different teams with four different managers. 

I'm thinking a feature team is where one team has representatives from each of the above? So the team is cross skilled and this will help in the people within the team also cross-skilling?

10:43 pm November 25, 2018

Is feature delivery currently understood? For example, would a Product Owner be able to explain how features have been forecast for delivery on a Product Backlog, so the release of value will be maximized?

If there is pull from stakeholders for feature-complete increments, that will inform the organization about the skills a “feature team” will need.

06:52 pm November 26, 2018

Here is the best and simplest way I can describe the difference.

  • Component teams will build individual components that are used by other teams to string together in order to provide a feature/value to the end user. Typically it will be done in serial (i.e. architecture, backend, middle tier, front end.)  
  • Feature teams will build all the components needed to deliver the feature to the end user regardless of the technology stack in which the code is needed.

What you describe as your current teams look like component teams to me.  Your assessment of a feature team is closer if all of those disciplines are needed in order to deliver the potentially releasable product increments.

I see that as the reason that Scrum defines Product Owners and Product Backlogs.  The work to build and maintain a product is in one place.  You could have component teams work from the same backlog but would you be building potentially releasable product increments of value to the end user in that case? 

11:22 am December 5, 2018

Maybe Jason's post doesn't actually describe component teams. At first sight, to me they look like organizational teams: operations does triage and handles customer queries, reporting covers reports, etc. The setup looks rather ok to me.

It is normally the development team(s) that you want to be feature, not component-based. That is, when building something, anything at all, the team must be able to cover the A to Z, and create something that can potentially be shipped to customers (whether internal or external) without the need of another team doing work on it. Better said, if, for instance, product requires work on both front end (customer facing) and back end, you'd need all work done within a single team that includes back end dev(s), front end dev(s), tester(s) - that would qualify as a feature team.

Conversely, if you have three separate teams, namely front end team, back end team, and QA team, now these would be component teams. 

11:40 am December 5, 2018

To put in a slightly different example; if you go to McDonalds and buy a complete product like, let's say a McChicken (my favorite as you might have guessed), that would be the complete product. Components of that complete product are:


Features are the bites you take, parts of the complete working product