The LeSS Framework
Large-Scale Scrum · Larman & VoddeWhat is LeSS?
Large-Scale Scrum (LeSS) is Scrum applied to many teams working together on one product. It is not a new or improved Scrum — it is about figuring out how to apply the principles, rules, and purpose of Scrum in a large-scale context, as simply as possible.
LeSS was created by Craig Larman and Bas Vodde based on their experience in large-scale product development. Unlike frameworks that add layers of process, roles, and artifacts as organizations scale, LeSS takes a ‘more with less’ approach — fewer roles, fewer artifacts, fewer processes — driving responsibility down to the teams closest to the work.
LeSS offers two configurations: Basic LeSS for 2–8 teams (up to ~80 people) and LeSS Huge for 8+ teams (up to thousands of people). Both maintain the core structure of Scrum: one Product Owner, one Product Backlog, one Sprint, and one potentially shippable Product Increment.
The framework is defined by LeSS Rules (mandatory structural elements), supported by LeSS Guides (optional practical advice), and informed by LeSS Experiments (field-tested practices with documented outcomes). The rules are minimal by design — they define the boundaries within which teams self-organize.
LeSS Principles
LeSS is grounded in ten principles that guide every decision. These principles prioritize simplicity, empiricism, and whole-product thinking over process prescription.
Large-Scale Scrum is Scrum
LeSS is not ‘Scrum plus extras.’ It applies standard Scrum elements in a multi-team context. One Product Owner, one Product Backlog, one Sprint, one potentially shippable increment — regardless of whether there are 3 or 33 teams.
Empirical Process Control
Inspection and adaptation of product, processes, organizational design, and practices. Empirical process control requires and creates transparency. More learning with less defined process.
Transparency
Based on tangible ‘done’ items, short cycles, working together, common definitions, and driving out fear in the workplace. Without transparency, empiricism is impossible.
More with LeSS
In empirical process control: more learning with less defined processes. In lean thinking: more value with less waste. In scaling: more ownership and purpose with fewer roles, artifacts, and special groups.
Whole-Product Focus
One Product Backlog, one Product Owner, one potentially shippable increment, one Sprint — regardless of team count. Every team works toward the whole product, not a component or layer.
Customer-Centric
Identify value and waste in the eyes of the paying customer. Reduce the cycle time from concept to cash. Teams work directly with real customers and users, not through intermediaries.
Continuous Improvement Towards Perfection
Create an environment of continuous improvement through experimentation. ‘Stop and fix’ when a problem surfaces rather than working around it.
Lean Thinking
Create an organizational system whose foundation is managers-as-teachers who apply and teach systems thinking and lean thinking, manage to improve, and practice Go See at the real place of work.
Systems Thinking
See the whole system, not just local parts. Understand the dynamics of the organizational system. Avoid local optimization that degrades the whole.
Queuing Theory
Understand the behavior of queues to manage flow. Small batches, short queues, and limited WIP create faster flow and shorter cycle times.
Structure & Rules
LeSS rules define the organizational design. They are intentionally minimal — the ‘barely sufficient’ framework for empirical process control and whole-product focus.
Organization
Structure the organization using real teams as the basic building block. Each team is self-managing, cross-functional, co-located, and long-lived. Teams are customer-focused feature teams — not component teams.
Product
There is one Product Owner and one Product Backlog for the complete shippable product. The PO shouldn’t work alone on refinement — teams work directly with customers, users, and stakeholders.
Sprint
There is one common Sprint for all teams, ending in one potentially shippable Product Increment. Sprint Planning consists of two parts. Sprint Review is shared. There is an Overall Retrospective in addition to team retrospectives.
Feature Teams
All teams are feature teams — cross-functional, cross-component, full-stack teams that can deliver end-to-end customer features. This is a hard rule, not a suggestion. Component teams are explicitly not part of LeSS.
Managers
Managers are optional. If they exist, their focus shifts from managing day-to-day product work to improving the value-delivering capability of the product development system. Managers practice Go See, encourage Stop & Fix, and favor experiments over conformance.
Roles
LeSS intentionally has very few roles — the same as Scrum. More roles means less responsibility to teams, more handoffs, and more coordination overhead. LeSS descales by removing roles, not adding them.
Product Owner
One PO for the entire product, regardless of team count. The PO has full content authority over the single Product Backlog. They focus on strategic prioritization and clarification, while teams work directly with customers for detailed understanding. The PO does not work alone — teams help with refinement.
Scrum Master
A dedicated, full-time role. One SM serves 1–3 teams. Crucially, the SM doesn’t focus on just one team — they focus on the overall organizational system. SMs are responsible for a well-working LeSS adoption, coaching teams, PO, and the organization.
Teams (Developers)
Self-managing, cross-functional feature teams of ~7 people. Every team can deliver a complete, end-to-end customer feature. Teams work directly with real customers and users. There are no component teams, no QA teams, no architecture teams — all skills live within feature teams.
No Additional Roles
LeSS does not have Release Train Engineers, Product Managers, Area Product Owners (in basic LeSS), Solution Architects, or program-level coordinators. Coordination happens through direct team-to-team collaboration, shared events, and shared code.
LeSS Events
LeSS events are standard Scrum events adapted for multiple teams. The key principle: as few cross-team events as possible, with maximum direct team-to-team coordination.
Sprint Planning Part 1 (shared)
All teams together with the Product Owner. The PO presents the highest-priority items. Teams self-select which items they’ll work on. Cross-team dependencies and coordination are discussed. Timeboxed to ~1 hour for a 2-week Sprint.
Sprint Planning Part 2 (per team)
Each team independently creates their Sprint Backlog. Teams may coordinate with each other during this phase for items with dependencies. The PO is available for clarification but teams drive the planning.
Daily Scrum (per team)
Standard 15-minute Daily Scrum per team. Cross-team coordination happens organically through team members attending other teams’ Daily Scrums or through ‘just talk’ direct communication.
Product Backlog Refinement (cross-team)
Multi-team refinement sessions where teams collaborate with the PO and real customers/users. Teams do the refinement — the PO facilitates access to customers, not requirements documents.
Sprint Review (shared)
One Sprint Review for all teams with real customers/users and stakeholders. Teams demonstrate the integrated product increment. The PO facilitates adaptive planning based on feedback.
Retrospectives (two levels)
Team Retrospectives happen first (per team, standard Scrum). Then an Overall Retrospective with team representatives, SM(s), PO, and managers (if any) to address cross-team and organizational systemic issues.
LeSS Huge
LeSS Huge is for products with more than 8 teams (and potentially thousands of people). It adds the concept of Requirement Areas to manage the scale while preserving the core LeSS principles.
Requirement Areas
The Product Backlog is divided into Requirement Areas — customer-centric groupings of related items (not architectural components). Each area has 4–8 feature teams working from an Area Product Backlog.
Area Product Owner
Each Requirement Area has an Area Product Owner (APO) who specializes in that area’s customer domain. The overall Product Owner and the APOs form the Product Owner Team, ensuring coherent whole-product direction.
Same Sprint, Same Increment
Even in LeSS Huge, there is still one common Sprint and one potentially shippable Product Increment. Each Requirement Area operates like a basic LeSS implementation, but all areas synchronize in the same Sprint.
Organizational Structure
LeSS Huge requires significant organizational restructuring — eliminating functional departments, removing component-team structures, and organizing around customer-centric requirement areas with self-managing feature teams.
Technical Excellence
LeSS places extraordinary emphasis on technical excellence. Without strong engineering practices, scaling Scrum creates scaling chaos. Technical practices are not optional nice-to-haves — they are essential structural elements.
Continuous Integration
All teams integrate their code continuously into one shared codebase. There are no team branches that live for days or weeks. Integration happens continuously throughout the day, validated by automated tests.
Test-Driven Development
TDD is practiced at unit and acceptance levels. Tests are written before code. The test suite serves as living documentation and a safety net for refactoring.
Shared Code Ownership
All teams can modify any part of the codebase. There are no code owners, no component boundaries, no handoffs. This is essential for feature teams to deliver end-to-end value.
Clean Code & Refactoring
Continuous attention to code quality. Refactoring is not separate work — it is part of how every feature is developed. The codebase should always be improving, not degrading.
Architecture
Architecture emerges through the work of feature teams, guided by a shared vision. There is no separate architecture team. Architectural decisions are made by the teams doing the work, supported by communities of practice.