Large-Scale Scrum (LeSS)

Many scaling frameworks add layers of roles, events and planning on top of agile teams. Large-Scale Scrum takes the opposite view. Its creators argue that adding structure to manage complexity usually creates more complexity, and that the better path is to simplify the organization so that Scrum can work at scale with as little extra process as possible. In LeSS, many teams work as if they were one large Scrum team: they share a single product, a single Product Owner, a single Product Backlog, a single Definition of Done and a single Sprint, and they deliver one integrated product increment together.

LeSS was developed by Craig Larman and Bas Vodde from their work with large product groups beginning in the mid-2000s, and they have described it in several books. Its guiding idea is descaling: simplifying the organization so that less coordination is needed, rather than adding roles to manage complexity. It comes in two forms: LeSS for about two to eight teams, and LeSS Huge for larger groups, which has been used with hundreds of people. LeSS is less widely adopted than SAFe but has strong support among practitioners who favor organizational change over process. For product leaders, Scrum Masters and engineering managers, LeSS offers a minimalist alternative for scaling agile.

Definition of Large-Scale Scrum (LeSS)

Large-Scale Scrum is a scaling framework built on the rules of Scrum, in which multiple feature teams work from one Product Backlog under one Product Owner in a common Sprint, producing one potentially shippable product increment, with additional events and guidance for coordination and organizational design.

It is an alternative to the Scaled Agile Framework (SAFe), builds directly on Scrum and is one of the main frameworks for agile at scale.

Key Principles

More with less. LeSS aims for fewer roles, artifacts and processes, and more responsibility for teams.

Whole-product focus. Teams think about the whole product and customer, not only their own component.

Feature teams. Teams are long-lived and cross-functional, able to deliver complete customer-centric features rather than working on one technical layer.

Systems thinking, lean thinking, empirical process control and continuous improvement toward perfection guide decisions about how the organization changes.

LeSS and LeSS Huge

Basic LeSS suits about two to eight teams. One Product Owner works with all teams, supported by the teams themselves in clarifying requirements.

LeSS Huge applies when there are more than about eight teams. The product is divided into requirement areas, each with an Area Product Owner and its own group of teams, under one overall Product Owner and one Product Backlog.

In both, there is still one product and one Sprint, so all work integrates into a single increment. LeSS also gives guidance on organizational design, such as reducing management layers and removing separate coordination roles that teams can handle themselves.

Importance of LeSS in Delivery and Engineering Operations

LeSS keeps the focus on the customer and the whole product. A single backlog and Product Owner prevent teams from optimizing their own components at the expense of the product.

It reduces coordination overhead. Fewer roles and layers mean fewer handoffs and less management between teams and customers.

It also drives organizational change. LeSS asks organizations to restructure around feature teams and remove unnecessary roles, addressing root causes rather than adding process. It builds broad product knowledge. Feature teams working across the whole product learn more of the system, which reduces dependence on a few specialists.

LeSS and Financial Management

Fewer coordination roles and layers can lower management overhead compared with heavier frameworks.

Feature teams reduce the waiting and handoffs between component teams, so funded capacity turns into delivered features more directly.

A single prioritized backlog makes it clear what the product group's whole budget is being spent on.

The organizational changes LeSS requires, such as restructuring teams and roles, take time and investment, and benefits may take several quarters to appear.

Common Challenges

LeSS requires significant structural change, such as moving from component teams to feature teams, which can meet resistance from managers and specialists.

A single Product Owner for many teams is a demanding role and depends on teams taking real responsibility for understanding customer needs.

Organizations looking for detailed prescriptions may find LeSS too minimal, since it deliberately leaves many decisions to the teams. Technical practices matter a great deal. Without continuous integration and automated testing, many teams cannot integrate their work into one increment every Sprint.