LeSS — Large-Scale Scrum

---

Origins

LeSS was developed by Craig Larman and Bas Vodde over more than a decade of large-scale agile transformations, primarily at Nokia, before being codified in the books Large-Scale Scrum: More with LeSS (2016) and earlier Practices for Scaling Lean & Agile Development (2010).¹

The framework's distinctive position: scaling Scrum should look like more Scrum, not different Scrum. Where SAFe adds release trains, program increments, and dedicated roles, LeSS doubles down on the original Scrum elements — one Product Owner, one Product Backlog, one Definition of Done — and adds only the minimum coordination machinery between teams.

The Core Principles

One Product Owner, One Product Backlog

The most controversial and distinctive LeSS commitment. Across all teams working on one product, there is exactly one Product Owner who owns one backlog. No team-level POs, no chief PO with proxies — one person responsible for the product's direction.

This is structurally simpler than alternatives but pushes a heavy responsibility onto the single PO. The framework addresses this by limiting LeSS to 2–8 teams (about 50 people). For larger contexts, LeSS Huge adds requirement areas.

Whole-product focus

Every team works on whatever is highest priority in the single backlog, not on a fixed slice. Teams are feature teams — broad, end-to-end, capable of picking up any work the PO sequences next.

Customer-centric over component-centric

LeSS explicitly opposes component teams. The framework treats them as a scaling anti-pattern that produces handoffs and dilutes ownership.

System-wide retrospective

In addition to team retrospectives, LeSS includes an overall retrospective covering the program as a whole. The two-level reflection is what allows system-level improvement that individual team retros can't produce.

Events at Scale

• Sprint planning happens in two parts. Part 1 brings representatives from all teams together to agree what each team will work on. Part 2 happens within each team to plan their selected work.
• Daily Scrum happens per team, with optional cross-team coordination.
• Sprint review is shared across all teams, with stakeholders.
• Sprint retrospective happens per team, followed by the overall retrospective.

LeSS Huge

For programs beyond 8 teams, LeSS Huge introduces requirement areas: large logical chunks of the product, each with its own area PO. The overall structure remains close to LeSS, just multiplied across areas. LeSS Huge has been used in programs of up to several thousand people, though the framework's authors acknowledge that at such scales, descaling is usually a better strategy.²

The Philosophical Position

LeSS sits closest to the descaling argument among the major frameworks. Larman and Vodde have repeatedly written that the best scaling move is usually no scaling — make teams broader, push more work into each team, eliminate the need for cross-team coordination wherever possible. When scaling is genuinely needed, LeSS aims for minimum sufficient structure.

This makes LeSS attractive to organizations that find SAFe's machinery oppressive but still need multi-team coordination. It also makes LeSS difficult to adopt in organizations that want the elaborate structure SAFe provides — LeSS will feel insufficient.

Where LeSS Works

• Product organizations with 2–8 truly cross-functional teams.
• Leadership willing to commit to a single PO with real authority.
• Engineering capable of feature-team work (broad skills, less component specialization).
• Cultural appetite for less ceremony, more team-level discipline.

Where LeSS Struggles

• Organizations attached to component teams. LeSS demands feature teams; resistance produces theatre.
• Programs where one PO genuinely cannot carry the load. LeSS Huge helps but adds complexity.
• Cultures that crave ceremony. The relative bareness of LeSS feels inadequate to teams accustomed to SAFe-style structure.
• Highly regulated domains where coordination ceremonies are required for compliance reasons.

Coaching Tips

Eliminate component teams first.

LeSS doesn't work with component teams. The reshaping is a precondition, not a consequence.

Give the PO real authority.

One PO across multiple teams requires real backing. Without it, the framework collapses into chief-PO-with-proxies despite the name.

Keep the team set small.

2–8 teams is the bound. Beyond that, either split into multiple LeSS programs or descale toward fewer broader teams.

Invest in feature-team capability.

Engineers need broader skills to do feature-team work. Pairing, mobbing, and cross-team rotation build this over time.

Use the overall retrospective seriously.

System-level improvement happens here. Without it, team-level retros optimize locally and miss the cross-cutting issues.

Resist adding ceremonies.

LeSS earns its keep by being lean. Adding "just one more sync" repeatedly turns it into SAFe-lite.

Summary

LeSS is the scaling framework for organizations that want to do as little scaling as possible. By holding tightly to one Product Owner, one backlog, and feature-team structure, it produces a system that looks like Scrum just larger — rather than Scrum buried under additional machinery. The framework rewards organizations with cultural appetite for less ceremony and engineering depth for true feature-team work. It struggles where either is missing. For programs that fit its preconditions, it's often the cleanest scaling option available.

Back to Scaling Agile