LeSS (Large-Scale Scrum) is a framework for scaling Scrum to multiple teams working together on one product. Created by Craig Larman and Bas Vodde, LeSS applies core Scrum principles—empirical process control, transparency, self-managing teams—to large-scale development while minimizing organizational complexity. The framework exists in two variants: Basic LeSS (for 2-8 teams) and LeSS Huge (for 8+ teams with requirement areas). Unlike heavyweight scaling frameworks, LeSS emphasizes "More with LeSS"—de-scaling organizations by removing unnecessary roles, artifacts, and processes that prevent teams from delivering value. At its heart, LeSS is simply Scrum scaled up.
What This Cheat Sheet Covers
This topic spans 15 focused tables and 117 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Core LeSS Principles
The ten LeSS principles provide the philosophical foundation that guides all decisions in a LeSS organization. These principles distinguish LeSS from traditional scaling approaches by emphasizing simplicity, learning, and systems thinking over imposed process complexity.
| Principle | Example | Description |
|---|---|---|
Single Product Backlog for all teams working together | LeSS maintains the core Scrum principles of empirical process control, transparency, and self-management at scale—it adds structure to coordinate multiple teams but remains fundamentally Scrum. | |
Teams inspect at Sprint Review, adapt process at Retrospective | • LeSS provides just enough structure to enable transparency and inspect-adapt cycles • teams continuously discover better ways of working rather than following a predefined process recipe | |
Everyone sees the same Definition of Done and actual progress | Visibility into real status, problems, and impediments is essential for empirical control—LeSS creates painful but necessary transparency that exposes organizational weaknesses. | |
Eliminate project managers; teams coordinate directly | • Avoid adding roles, artifacts, or processes—each addition removes responsibility from teams • prefer solving problems by simplifying the organization rather than adding complexity | |
Teams integrate work every Sprint into one shippable product | • Customers buy the whole product, not parts—optimize for overall product delivery, not individual team output • unintegrated work has no value |