In the last months, I’ve had many conversations in the LeSS community and in the current product I work in about Requirement Areas. From those discussions, I’ve discovered new ways of explaining them. Here, I’d like to share some of these.

What are Requirement Areas?

Requirement Areas is a grouping of items on the product roadmap used to create a view on the Product Backlog. This view helps us structure the teams accordingly.

Then what is the product roadmap? A product roadmap is a high-level view of the Product Backlog. In the LeSS books, Craig and I talk about items in the backlog that can have ancestors. Nowadays, I refer to items that have ancestors as “roadmap items”. Together they form a high-level view of the Product Backlog, which is usually referred to as the Product Roadmap. Requirement Areas is a grouping or categorizing items on the product roadmap that we use for structuring the work.

Why Requirement Areas?

The original reason for starting this grouping, which began about 20 years ago with the first LeSS Huge adoption, was to support the Product Owner in keeping an overview of the development and prioritization. By having a grouping, we can create a view of the Product Backlog according to this categorization and structure the teams and PO around this. This enables us to scale from roughly 8 teams to any size product development.

Requirement Areas also give other benefits since they help in facilitating multi-team events. An area is always between 4-8 teams, so the multi-team sessions always have a reasonable amount of people to use practices as mixed-up groups in multi-team Product Backlog Refinement.

How to create Requirement Areas?

Creating Requirement Areas is not hard. The hardest part is that they are different from structures that people are used to. To create them, you need to understand what the main functionality will be the focus in development for the next year(s): the product roadmap. When you have that, do the following:

1. Group related items in the roadmap that are related to affinity.
2. See if you can think of a name.
3. Imagine how many teams would be required to work on these.
4. If the number of teams is smaller than 4, go to step (1) and redo the grouping or combine categories.
5. If the number of teams is larger than 8, consider splitting the category or revisit (1) and try again.

Notice: The key factor that defines an area is the number of teams working there because the purpose of areas is to structure the work. Never have areas smaller than 4 teams.

What are not Requirement Areas?

There are a couple of common mistakes when using Requirement Areas. The biggest one is to have small areas (smaller than 4 teams). This is resolved by adding two small ones.

Other common misconceptions are:

• Confusing them with Product Areas. A Product Area is a grouping of functionality in the product and not a functionality in the roadmap. This difference is significant! Your product might have a large amount of functionality related to “financial reporting” but when you do not plan to build new functionality in financial reporting, then you would never have a Requirement Area for that. For creating areas, look at the roadmap, not the product.
• Using the Product Architecture for creating Requirement Areas. A Requirement Area is a grouping in the roadmap, not a split based on architecture. When you split based on architecture and structure teams accordingly, that is referred to as Development Areas. These are not recommended because all the component team dynamics will manifest in development areas.
• Requirement Areas are often viewed as separate Products. Organizations frequently transition from many small products to one large product when adopting LeSS. During this process, they often confuse Requirement Areas with what they previously called a Product. This situation aligns with the misconception (2) but is common enough to warrant explicit mention.

There is a lot more to say about Areas, but for this blog, I’ll leave it here. More in the next blog.