Skip to main content

Feature teams vs Component teams

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

Hello

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:



Bun

Sauce

Burger

Lettuce

Sauce

Bun



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


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.