Large-Scale Scrum (LeSS): Feature Teams and When to Use It

Most frameworks for scaling Agile answer the question “how do we add more process to coordinate more teams?” LeSS (Large-Scale Scrum) asks a different question: “how do we keep the simplicity of single-team Scrum while working with multiple teams?” It’s a bet on simplicity, and a harder bet than it looks.

That reframing produces a radically different answer. Instead of adding layers (SAFe’s Agile Release Trains and Release Train Engineers), LeSS removes structure. One Product Owner for the whole product. One Product Backlog for all teams. Teams that each work on any part of the product, not dedicated sub-products.

Bas Vodde and Craig Larman, who developed LeSS, were deeply skeptical of the organizational tendency to solve coordination problems by adding management structure. Their view was the opposite: coordination problems often are the management structure. More hierarchy, more handoffs and more roles create more coordination overhead, not less.

LeSS is their prescription: when you need to scale Scrum, scale the product ownership and the team structure, and leave the management overhead where it is.

How Does LeSS Work With 2-8 Teams?

LeSS for 2-8 teams is essentially Scrum with adjustments for multi-team coordination:

• One Product Owner, one Product Backlog
• One shared Sprint, with teams each picking items from the shared backlog at the start
• Sprint Planning happens in two parts: a joint session where teams pick items (Sprint Planning One) and individual team sessions where they plan how (Sprint Planning Two)
• Cross-team coordination during the Sprint, mostly by teams talking to each other directly, with options such as multi-team meetings or a Scrum of Scrums
• A combined Sprint Review where all teams show their work together
• Both team-level and Overall Retrospectives

LeSS Huge (8+ teams) adds a small amount of structure — an Area Product Owner for each Requirement Area — but still keeps the fundamental discipline of one overall Product Owner and one overall Product Backlog.

What LeSS explicitly doesn’t add: program managers, coordination teams, separate roadmaps per team, dedicated “architectural” teams, separate QA organizations. These additions are common in scaled environments and LeSS treats most of them as organizational smells that point to structural problems.

Why Does LeSS Use Only One Product Owner?

The single Product Owner is the most controversial element of LeSS, and it’s also the most important.

In most multi-team scaling approaches, each team gets its own Product Owner who manages their own sub-product or component. This seems efficient. The practical result is that the product fragments: each PO optimizes their piece, teams work on separate things, integration is someone else’s problem, and nobody is making whole-product prioritization decisions.

LeSS insists on one PO because whole-product thinking requires whole-product ownership. If the most valuable thing for the product as a whole is for all three teams to work on the same feature area this Sprint — because the integration is complex and coordinated effort matters — a single PO can make that call. In a fragmented multi-PO model, nobody has that authority. This is the same accountability the Scrum Guide gives a single team’s Product Owner, stretched across the whole product.

The constraint: one PO for 5+ teams is genuinely hard. The PO needs to be deeply connected to users, able to maintain a coherent product vision across many parallel workstreams, and available enough to answer team questions without becoming a bottleneck. This requires a different kind of person than the typical single-team PO and a different level of organizational support.

What Are Feature Teams?

LeSS requires feature teams — cross-functional teams that can work on any feature in any area of the product. The alternative is component teams, which own specific components or layers of the architecture.

Component teams feel efficient because everyone on the team has deep expertise in their area. The problem: features require integration across components. A feature that requires changes to the UI, the API, and the database requires coordination between three component teams, each with their own sprint plans and priorities. Coordination overhead is enormous. Features move slowly. Blame for delays is diffuse.

Feature teams require generalists or T-shaped developers — people with depth in their specialty and breadth across the system. They’re harder to build than component teams. Transitioning from component teams to feature teams is one of the most common LeSS adoption challenges.

The reward: feature teams can be assigned any work, which means the Product Owner can truly prioritize the most valuable features without being constrained by which team “owns” which component.

When to Choose LeSS Over SAFe

LeSS and SAFe are the two dominant choices for scaling Scrum beyond 5-6 teams. They make radically different tradeoffs:

LeSS is simpler, more consistent with the original Agile values, and requires more organizational commitment (genuinely flat teams, real product ownership, actual feature teams). It’s the right choice when: leadership is willing to flatten organizational structure, teams have or can develop the breadth to be genuine feature teams, and the organization genuinely wants Agile rather than managed Agile.

SAFe is more complex, provides more scaffolding, and is easier to adopt within existing hierarchical structures without requiring radical change. It’s the right choice when: the organization needs to coordinate many teams with existing organizational structure mostly intact, governance requirements are significant, or leadership wants to scale Agile without restructuring reporting lines.

LeSS is the purist’s choice. SAFe is the pragmatist’s choice. Both involve real tradeoffs.

Why Do LeSS Adoptions Fail?

Component team resistance: Teams that have built deep component ownership resist becoming feature teams. This is understandable — becoming responsible for areas of the system you don’t know is uncomfortable. Organizations that implement LeSS without transitioning to feature teams get many of the coordination costs with fewer of the benefits.

Insufficient Product Owner capacity: A single PO managing five teams who also attends other organizational commitments is not a functional arrangement. The PO becomes a bottleneck. Teams wait for answers. This is often misdiagnosed as a LeSS problem when it’s a resourcing problem.

Leadership tolerance for the messy middle: The transition from component teams to feature teams is disruptive. Velocity drops. Teams work in unfamiliar code. The organization needs to tolerate this transition period without reverting to comfort. Many don’t.

Premature complexity: Some organizations adopt LeSS Huge when they should be doing basic LeSS, or adopt LeSS when they only have three teams and Scrum with good cross-team coordination would be sufficient.

Organize Around the Whole Product, Whatever Framework You Use

Regardless of what scaling framework you use, the principle of whole-product focus is worth internalizing. When teams are organized around components or sub-products and optimize independently, the whole product suffers. When the product is the organizing principle and teams are organized to serve the product, integration and prioritization decisions improve.

You don’t have to implement LeSS to ask: are our teams organized to optimize the whole product, or are they optimizing their pieces? The answer tells you whether your coordination structure serves the product or serves the teams — and those two are not always the same thing.