Requirement Areas
Feature teams scale nicely, but when their number goes above eight teams additional structure is needed. Requirement areas provide this structure and complement the concepts behind feature teams. A requirement area is a categorization of the requirements leading to different views of the Product Backlog.
The Product Owner (PO) groups every Product Backlog item under exactly one requirement category—its requirements area. After this, he generates different views on the overall Product Backlog—called an Area Backlog. The Area Backlogs are prioritized by an Area Product Owner who specializes in part of the product—from a customer perspective. Each Requirement Area has several feature teams working from the Area Backlog, as shown in Figure 1.
Requirement areas are scaled-up feature teams. Scaling up by structuring teams according to the product’s architecture is called development areas. The table below summarizes the differences.
| Requirement Area | Development Area |
|---|---|
| organized around customer-centric requirements | organized around product’s architecture |
| collective subsystem code ownership | code ownership per subsystem |
| temporary in nature; should change over the lifetime of the product, but not at every iteration | tends to be more fixed over the lifetime of the product |
| focus on the customer, using customer language | focus on the architecture, using technology language |
Development areas are not recommended and are only shown to show the contrast with Requirement Areas.