What Is LeSS (Large-Scale Scrum)? Principles, Structure & When to Use It

LeSS (Large-Scale Scrum) is a framework for scaling Scrum to multiple teams working together on a single product. Developed by Craig Larman and Bas Vodde, LeSS takes the opposite approach from many enterprise scaling frameworks: rather than adding new roles, processes, and ceremonies as teams grow, LeSS seeks to keep things as simple as possible — applying Scrum’s principles directly at scale with minimal additional structure.

The core philosophy of LeSS is that organizational complexity is often self-imposed. Most of what makes scaling hard are not inherent difficulties of coordination, but rather dysfunctions created by organizational structures that separate teams, fragment product ownership, and introduce bureaucratic processes where direct collaboration would work better.

Two Versions of LeSS

LeSS (Basic)

For 2–8 teams working on a single product. The structure mirrors Scrum almost exactly, with one addition: all teams share a single Product Owner, a single Product Backlog, and a coordinated Sprint — while each team runs its own Daily Scrum and Sprint ceremonies.

LeSS Huge

For more than 8 teams. LeSS Huge introduces “Requirement Areas” — large feature areas of the product, each with an Area Product Owner — to manage the increased complexity. The overall Product Owner retains responsibility for the whole product and coordinates across Area Product Owners.

Core Principles of LeSS

One Product Owner

All teams in a LeSS system share a single Product Owner who maintains the product’s strategic direction and a single prioritized Product Backlog. This creates genuine product cohesion rather than a collection of team-level backlogs that may diverge from each other.

One Product Backlog

All work across all teams comes from a single backlog. Teams pull work from this shared backlog at sprint planning, enabling the Product Owner to prioritize across the entire product rather than within team-level queues.

One Potentially Shippable Product Increment

All teams deliver a single integrated product increment at the end of each sprint. This requires teams to work on the same codebase, coordinate integration continuously, and maintain shared quality standards.

Synchronized Sprints

All teams operate on the same sprint cadence. This enables coordinated sprint planning, integrated demos, and shared retrospectives — keeping teams aligned rather than operating on incompatible rhythms.

LeSS Ceremonies

Sprint Planning Part 1 (All Teams)

All teams meet together with the Product Owner to discuss priorities and clarify items in the backlog. Teams self-select work items based on dependencies and skills.

Sprint Planning Part 2 (Per Team)

Each team plans its own sprint in detail — breaking selected items into tasks and creating its sprint plan.

Sprint Review (All Teams)

All teams demonstrate their work together in a single integrated sprint review, showing the combined product increment.

Overall Retrospective

A retrospective that brings together representatives from all teams to identify system-level improvement opportunities that span multiple teams.

LeSS vs. SAFe

	LeSS	SAFe
Philosophy	Minimize additional structure	Provide comprehensive framework
Roles	Few new roles beyond Scrum	Many new roles (RTE, Business Owners, etc.)
Complexity	Low	High
Best for	Teams willing to change organization to fit agile	Organizations that need agile to fit current structure
Scale	2–8+ teams	50–125+ people

LeSS requires more organizational willingness to change structure; SAFe provides more scaffolding for organizations that need to work within existing structures.

Key Takeaways

LeSS is the scaling framework for teams that believe the best way to scale agile is to apply its principles directly — and to restructure the organization to support them — rather than to wrap them in additional process. It produces genuine agility at scale for organizations willing to make the organizational changes it requires, but is less suited to organizations that need to preserve existing management structures while adopting agile practices.