What is LeSS?
LeSS (Large-Scale Scrum) is a framework for scaling Scrum to multiple teams working on a single product. The core philosophy is radical simplicity: rather than adding new processes, roles, and artefacts, LeSS asks "why can't we use Scrum as-is?" and only adds what is truly necessary.
LeSS is built on the premise that most scaling problems are really organisational problems — component teams, technical silos, and handoff culture — that new processes cannot solve. The solution is usually to change the organisation.
The 10 LeSS Principles
Roles — No New Ones
LeSS has the same three roles as Scrum. No ART, no RTE, no Chief Product Owner below LeSS Huge threshold.
One Product Backlog
The single most important structural rule in LeSS: there is only one Product Backlog, owned by one Product Owner. Teams pull from this shared backlog based on capacity and skill.
One Product Backlog for all teams → Prioritised by business value by the Product Owner → Items refined in multi-team refinement sessions → Teams select items at Sprint Planning 1 (self-organising) → No "team backlogs" — those are just Sprint Backlogs Product Backlog Item (PBI) readiness checklist: ✓ Customer problem and acceptance criteria clear ✓ Split small enough for one team to complete in one Sprint ✓ Dependencies with other PBIs identified ✓ Estimation consistent across teams
Sprint Planning
LeSS has a unique two-part Sprint Planning designed for multi-team coordination without a coordinator role.
Sprint Planning 1 — What?
All teams together. PO discusses the top items. Teams self-select which PBIs to work on. Items that require coordination across teams are identified. Multi-team work is agreed.
Sprint Planning 1 (whole ART, 1–2 hours) → PO presents top Product Backlog items → Teams volunteer for PBIs based on capacity → Dependencies between teams surfaced and planned → Multi-team items: teams agree who does what → Each team takes their selected items away
Sprint Planning 2 — How?
Each team plans independently. Teams may invite members of other teams when cross-team design is needed.
Sprint Planning 2 (per team, up to 2 hours) → Team creates Sprint Goal → Breaks PBIs into tasks → Identifies cross-team coordination points → Shared planning optional: teams co-locate if needed
Sprint Review — The Bazaar
In LeSS, the Sprint Review often uses the Bazaar (or Open Space) format — teams set up demonstration stations and stakeholders walk around, interacting with each team's work. This scales better than a single sequential demo.
Sprint Review Bazaar format: → Each team sets up a station with their working software → Stakeholders circulate freely, interact with any team → PO and teams capture feedback in real time → Product Backlog adjusted based on stakeholder input → Duration scales with number of teams (30 min/team max)
Retrospective Structure
LeSS has two retrospective levels — team and overall. The overall retrospective is the key scaling mechanism for process improvement.
| Retrospective | Who | Focus | Timebox |
|---|---|---|---|
| Team Retrospective | Each team separately | Team-specific improvements; sprint execution | 45 min/week of Sprint |
| Overall Retrospective | PO + SM + team reps | Cross-team issues; organisational impediments; systemic problems | 1–2 hours |
LeSS Huge
For products with more than 8 teams (roughly 50–100+ people), LeSS Huge adds one structural element: Requirement Areas and Area Product Owners.
LeSS vs SAFe
| Dimension | LeSS | SAFe |
|---|---|---|
| New roles | None (below LeSS Huge) | RTE, System Architect, Product Management, Business Owners |
| Cadence | Sprint (2 weeks) | Sprint + PI (8–12 weeks) |
| Synchronisation | One shared Sprint | PI Planning event |
| Product Backlogs | 1 (always) | Program Backlog + Team Backlogs |
| Organisational change | High (eliminates component teams) | Lower (overlays on existing org) |
| Best for | True product companies, ≤8 teams | Large enterprises, existing hierarchy |
| Overhead | Minimal | Significant |
LeSS Anti-Patterns
| Anti-Pattern | Problem | Fix |
|---|---|---|
| Component teams | Teams can only work on their component; features require coordination | Reorganise into cross-functional feature teams |
| Multiple Product Owners | "LeSS" with one PO per team is just parallel Scrum | One PO, one Product Backlog, always |
| Fake LeSS over hierarchy | LeSS labels on command-and-control organisation | Structural change is required; LeSS exposes organisational dysfunction |
| Skipping Overall Retro | Systemic issues never surface; each team firefights alone | Overall Retro is non-negotiable; it is the improvement engine for the system |
| SM as team coordinator | SM micromanages cross-team work | Teams self-coordinate peer-to-peer; SM removes system impediments |
LeSS Cheat Sheet
Rules (non-negotiable) → One Product Owner; one Product Backlog; one Sprint for all teams → One Definition of Done for the whole product → One potentially shippable Product Increment per Sprint → No component teams; cross-functional feature teams only Events Sprint Planning 1 → all teams + PO; self-select PBIs Sprint Planning 2 → per team; break into tasks Daily Scrum → per team (coordinate cross-team ad hoc) Sprint Review → Bazaar format with stakeholders Team Retro → each team separately Overall Retro → PO + SM + reps after team retros LeSS Huge (8+ teams) → Requirement Areas (customer-centric groupings) → Area Product Owner per area → Area Product Backlog (view of overall backlog) → No "Chief SM" or new coordination roles Scaling rule of thumb 2–8 teams → LeSS (basic) 8+ teams → LeSS Huge Hundreds → consider multiple products