LeSS — One Product, Many Teams, One Backlog

Large-Scale Scrum (LeSS) starts from a provocative premise: most scaling problems are not scaling problems at all — they're organisational problems that scaling frameworks help organisations avoid fixing.

Created by Craig Larman and Bas Vodde, LeSS deliberately adds as little as possible to standard Scrum. The name is literal: LeSS is Scrum, with less overhead, less bureaucracy, and less of the cruft that grows when you add coordination layers.

Learning Objectives

• Explain the key principles that distinguish LeSS from other scaling frameworks
• Describe the LeSS organisational model: one Product Owner, one backlog, many feature teams
• Compare LeSS and LeSS Huge for different organisation sizes
• Identify how LeSS handles sprint ceremonies at scale

The Core LeSS Principle: One Team, Scaled Up

LeSS treats the entire multi-team group as one big Scrum team, not as a collection of separate teams. This manifests in several ways:

One Product Owner: Not one PO per team — one PO for the entire product. This forces genuine prioritisation across all teams and prevents the "but our team's PO said this was priority 1" problem.

One Product Backlog: All teams pull from the same backlog. There are no team-specific sub-backlogs. This eliminates the coordination problem of "which backlog item blocks which other team's backlog item" — there's just one list, one order, one source of truth.

Multiple Feature Teams: Each team is a full-stack, end-to-end feature team capable of delivering complete features — not a component team that only owns one layer (frontend, backend, database). This is the most radical part of LeSS and the hardest to implement in existing organisations.

Feature Teams vs. Component Teams

This distinction is central to LeSS and worth dwelling on.

Component teams (the traditional model):

• Team A owns the frontend
• Team B owns the backend API
• Team C owns the database and services
• Problem: delivering any user-visible feature requires coordination between all three teams — every feature is a dependency chain

Feature teams (the LeSS model):

• Each team can deliver a complete user-visible feature end-to-end
• Teams cross component boundaries without permission
• Problem: requires multi-skill developers, shared codebase ownership culture, and willingness to let "your" component be changed by another team

The transition from component to feature teams is a significant organisational change — and it's the reason many organisations attempt LeSS but retreat to component teams under pressure.

For QA: In a feature team model, QA is fully embedded within the team and owns end-to-end testing for the features that team delivers. There's no central QA team that tests everyone's output — quality is the team's responsibility.

LeSS vs. LeSS Huge

LeSS has two variants:

LeSS Huge introduces Requirement Areas — groupings of related features that a subset of teams work on. Each Requirement Area has an Area Product Owner who manages that subset of the backlog. The main Product Owner coordinates across Areas.

This adds one organisational layer while keeping everything else flat.

LeSS Ceremonies

LeSS keeps most standard Scrum ceremonies but adapts them for multiple teams:

Sprint Planning — split into two parts:

• Part 1: All teams + PO together to discuss priorities and which team takes which items
• Part 2: Each team separately to break down their items and plan capacity

Daily Scrum: Each team runs its own Daily Scrum independently.

Sprint Review: One joint review with all teams presenting their increments to stakeholders.

Overall Retrospective: After individual team retrospectives, all teams + Scrum Masters + PO meet to discuss cross-team systemic issues.

Coordination between teams: LeSS deliberately provides no mandated coordination ceremony — teams self-organise through informal communication, scouts (developers who attend another team's meetings), and open spaces.

What LeSS Is NOT

LeSS is not a lighter version of SAFe. It's a deliberate anti-pattern to the SAFe approach. Where SAFe adds layers, roles, and ceremonies, LeSS removes them. Where SAFe creates coordination roles (like Release Train Engineer), LeSS says "the teams should figure it out."

Pro Tip: LeSS is philosophically pure but organisationally demanding. It requires executives to trust teams, product management to genuinely do one-backlog prioritisation, and developers to genuinely work across component boundaries. If any of those conditions don't exist, LeSS will be abandoned within 6 months and replaced with something more structured. Be honest about your organisation's readiness before advocating for LeSS.

Summary

• LeSS treats multiple teams as one big team, not a collection of teams
• One Product Owner + one Product Backlog eliminates cross-team backlog coordination
• Feature teams (vs. component teams) are the hardest but most important structural change
• LeSS Huge adds Requirement Areas for 8+ team contexts
• LeSS is intentionally minimal and requires organisational maturity to sustain