Domain Teams and Product Definition

A bunch of teams are responsible for various domains, be it systems or services. Each domain team has its own backlog. For example, in an e-commerce company, there are domain teams responsible for website, OMS (Order Management System), WMS (Warehouse Management System), payment system, etc. They develop features from those domains, such as adding a payment method, managing shared order, tracking shipping status, etc.

What change do we bring onto these teams in LeSS adoption? There are two essential elements in LeSS organizational design - feature team and one product backlog. How does this domain team structure differ from LeSS structure?

One Product Backlog or Feature Team?

At first glance, these domain teams seem like feature teams, as they are customer oriented to some extent. Then, the change would be towards one product backlog. Instead of each team focusing on one domain (team A/B/C for domain A/B/C respectively), all teams will work on whatever features at the top of the backlog.

Let's look at a product backlog as below - all items belong to only one domain. A/B/C in the backlog indicates the domain each item belongs to.

In this case, the domain teams are indeed feature teams, while the main change would be to share one product backlog for maximizing the value delivery globally, i.e. among all domains. In order to share one product backlog, the teams need to transition from single-domain to multi-domain.

Furthermore, let's look into customer value. Does value come from one domain or across multiple domains? How much percentage from one domain, and across domain? Let's look at another product backlog as below - many items are cross-domain.

In this case, the (single-)domain teams are essentially component teams. If we keep them intact, teams can't deliver many items from end to end. Therefore, the first change would be to create cross-domain feature teams 1/2/3. Team 1/2/3 can be fully cross-domain, each team covering A+B+C; or partially cross-domain, e.g. covering A+B/B+C/A+B+C by team 1/2/3 respectively.

Often, we don't introduce another dimension of specialization for these feature teams any more. Instead, we let them share one product backlog. However, if necessary, we can still take smaller step in first creating cross-domain feature team specializing in some customer dimension.

In either case of the above backlogs, we will create multi-domain teams, but for different reasons. When values come from single domains, those (single-)domain teams are feature teams, multi-domain teams are created to globally maximize value delivery (further refer to Number of backlogs and multi-learning: 4) specialized feature team). When values come across domains, those (single-)domain teams are component teams, multi-domain teams are created to first speed up end-to-end delivery (further refer to Number of backlogs and multi-learning: 2) functional team and component team).

Product Definition

The deeper meaning of feature team connects to the product definition. "The definition of feature is dependent on the definition of product. The product bounds the feature, and the feature is end-to-end within the product." (further refer to Is team in Scrum feature team?) So, when single domains are defined as products, those (single-)domain teams are feature teams. When multiple domains all together are defined as a product, those (single-)domain teams are not feature teams anymore; the feature teams in the new context need to be cross-domain teams.

This change relates more to the LeSS guide "feature team adoption map" as below.

In fact, Y-axis shows the gradual expansion of product definition. The scope of feature team gets broader - from single-domain to multi-domain - when the product definition gets broader. In fact, by creating one product backlog to include multiple domains, we implicitly expand the product definition.

In the LeSS guide "define your product", one of the questions that expands product definition is "our product is part of? what problem does the product solve for end-customers?". Let's apply this question in the example of e-commerce. Initially, we may treat OMS as a product, and OMS team is a feature team. Then, as OMS product is part of the e-commerce solution, we expand our product definition to e-commerce. OMS becomes a component in the expanded product, thus OMS team becomes a component team. To make it a feature team, we expand its scope to e-commerce.

In the same guide, there are also questions that restrain the product definition as practical. One of them is "what is the product vision? who are the customers? what is the product's customer domain?". Applying this question here, it is also possible that the company decides to focus on developing an OMS or payment system rather than the whole e-commerce solution, then, OMS or payment system becomes the product. Accordingly, OMS or payment teams become feature teams.

In conclusion, the change on the domain team structure is closely connected to product definition. A feature team often becomes a component team when product definition expands, while product definition may be implicitly expanded when creating one product backlog. In fact, the fundamental change is the expansion of product definition!