In my training classes we frequently discuss scaling agile with feature teams versus component teams. To help distinguish between the two types of teams it is important to consider the nature of the product backlog items that you might typically see in the product backlog for each type of team. In my classes I describe the difference with a simple rule of thumb:
That which is a feature to a component team is a task to a feature team.
That’s a complex sentence, so let’s break it down by using an example. Let’s say an end customer wants the following feature:
“As an inventory manager I want to remove a product from inventory so that I no longer offer it for sale.”
Feature Teams & User Stories
If we were to give this feature description to a feature team, it would appear as a user story in the feature team’s product backlog, as shown in Figure 1.
Figure 1. The diverse nature of feature teams means they can perform all of the tasks necessary to complete an end-customer valuable feature.
A feature team would have all the skills to perform the necessary task-level work to get the job done. In particular, assuming a three-tier architecture, team members would work on tasks related to the GUI, middle-tier, and database parts of this story (as shown in Figure 2’s sprint backlog). The blue brick in this picture is the feature (Remove Product From Inventory), the green cubes are tasks.
Figure 2. A feature team breaks each sprint backlog item into its component tasks.
Component Teams & User Stories
Now let’s look at how that same feature might be handled if implemented by component teams, rather than a feature team. We’ll start by assuming that we have created component teams along architectural boundaries. If so, then in a three-tiered architecture, we would have a GUI team, a middle-tier team, and a database team.
In such a scenario, there would be no one team to whom we could give the “Remove a Product from Inventory” user story and expect that it would have all of the necessary skills to complete the story. Instead, we would break the desired feature into three separate “stories,” each appropriate to the specific architectural layer component team, as shown in Figure 3.
Figure 3. Component teams work on the part of a feature that matches their specialized skillsets or asset area.
So the database team might have a product backlog item like: “As a middle-tier programmer I want an API for removing items from the database so that I can complete my business logic.”
From the database team’s perspective, this item looks like a “feature” that it needs to develop. However, to a feature team, this would have been one of several “tasks” that make up the overall story “Remove a Product from Inventory.” Hence, that which is a feature to a component team is a task to a feature team.
Figure 4 visually summarizes this concept.
Figure 4. That which is a feature to a component team is a task to a feature team.
I hope you find this simple heuristic helpful in easily identifying and distinguishing between component and feature teams.