LeSS
LeSS — Large-Scale Scrum — keeps one Product Owner, one Product Backlog, one Sprint and one shippable Increment, no matter how many teams. It scales by removing organisational structure rather than adding it, which makes it the most demanding scaling framework to adopt and the closest to actual Scrum. This page covers the ten principles, the rules-guides-experiments layering, every LeSS event, and both variants.
- LeSS Basic
- 2–8 teams
- LeSS Huge
- 8+ teams
- Principles
- Ten
Scaling by subtraction
Start with what usually happens when a product outgrows one team. A second team appears, then a third. Someone notices that three Product Owners are now prioritising against each other, so a coordinator is hired above them. Integration keeps slipping, so an integration team is created. Six months later there is a programme manager, a release manager, a steering committee, and a set of hand-offs between them — and delivery is slower than it was with one team.
LeSS treats that whole chain as the disease, not the cure. Its answer is to scale Scrum by adding as little as possible: one Product Owner for the entire product, one Product Backlog, one Sprint that every team shares, and one integrated Increment at the end of it. No new role sits above the team. No programme layer sits between the teams and the customer.
The framework's own word for this is descaling. Instead of adding machinery to manage coordination, it removes the organisational boundaries that created the need for coordination in the first place. The clearest example is the team itself: component teams, each owning one technical layer, are dissolved into feature teams that can take a customer-visible slice from idea to production without handing it to anyone.
The ten principles
LeSS is deliberately thin on rules and thick on principles — the rules tell you what the structure must be, the principles tell you how to decide everything the rules leave open. There are ten of them, and they are not decoration: when a LeSS adoption goes wrong, it is almost always because a decision was made against one of these while the rules were technically still followed.
| Principle | What it actually means |
|---|---|
| Large-Scale Scrum is Scrum | Not a new framework built on Scrum ideas. Every Scrum rule still applies; LeSS only says how it works with many teams. |
| Empirical process control | Inspect the real product and the real organisation every sprint, then adapt. No up-front plan survives contact, so do not build a process that depends on one. |
| Transparency | Based on shippable product, short cycles, common definitions and open workspaces — not on status reports that are transparent about someone's opinion of progress. |
| More with less | Fewer roles, fewer artefacts, fewer processes. Every addition must earn its place; the default answer to "should we add a role" is no. |
| Whole-product focus | One backlog, one Definition of Done, one Increment. A team's output only counts when it is part of the whole shippable product. |
| Customer-centric | Teams learn to tell customer problems from internal ones, and work is ordered by customer value — not by which internal department shouted. |
| Continuous improvement towards perfection | The stated goal is a product with zero defects delivered any time the customer wants it. You will not reach it; the point is the direction, not the arrival. |
| Systems thinking | Optimise the whole, not the parts. A team hitting 100% utilisation while the product ships late is a local optimum making the system worse. |
| Lean thinking | Managers act as teachers who improve the system, standing on the two pillars of respect for people and continuous improvement. |
| Queueing theory | Understand how batch size, work-in-progress limits, variability and utilisation behave. High utilisation plus large batches equals long queues — this is arithmetic, not culture. |
Rules, guides and experiments
LeSS separates its content into three layers with very different authority, and knowing which layer a statement belongs to is the difference between adopting the framework and cargo-culting it.
Rules — mandatory
The minimal definition of LeSS: one Product Owner, one Product Backlog, one shared Sprint, one Definition of Done, feature teams. Break a rule and you are no longer doing LeSS — which is a legitimate choice, but say so honestly.
Guides — tested advice
Practices that have worked in many adoptions: how to run Sprint Planning Two, how to form feature teams, how a Product Owner works with many teams. Strongly recommended, not required.
Experiments — try and see
Things that worked somewhere and failed elsewhere, published with both outcomes. LeSS deliberately lists "experiments to avoid" alongside promising ones.
This layering is why LeSS documentation is thin where SAFe's is thick. LeSS claims that beyond a small set of structural rules, the correct practice depends on the organisation, so publishing a detailed prescription would be dishonest. The trade-off is real: LeSS gives you less to copy and therefore demands more judgement from whoever leads the adoption.
What LeSS keeps, and what it removes
The roles in LeSS are the Scrum roles and nothing else. One Product Owner owns the ordering of the whole Product Backlog and talks to teams directly rather than through business analysts. The teams are feature teams of three to nine people, cross-functional and long-lived. A Scrum Master serves one to three teams full time — the "full time" is a rule, because a part-time Scrum Master reliably reverts to being a coordinator.
The removals are the harder half. There is no project manager, no programme manager, no team lead assigning work, no separate architecture group deciding for the teams, no analysis or testing department, no PMO between the Product Owner and the customer. Existing managers do not disappear — but their job changes from directing work to improving the system the work runs through.
The LeSS events, one by one
All teams run one shared Sprint of the same length, starting and ending on the same day. The events are the Scrum events with a defined answer to "what happens when eight teams need to do this at once".
| Event | Who attends | What comes out of it |
|---|---|---|
| Sprint Planning One | PO + reps from every team | Which team takes which items, and the dependencies between them made visible |
| Sprint Planning Two | Each team separately | That team's own plan; teams with shared work may plan in the same room |
| Daily Scrum | Each team separately | The team's day. Cross-team sync happens through observers, not a bigger meeting |
| Overall PBR | PO + all or several teams | Shared understanding of upcoming items and how to split them across teams |
| Sprint Review | PO + all teams + customers | One review of one integrated Increment — commonly run as a bazaar of stations |
| Team Retrospective | Each team separately | Improvements the team can make on its own |
| Overall Retrospective | PO, Scrum Masters, managers, team reps | Improvements to the system across teams — the one event managers must attend |
Between the events, coordination is deliberately left informal — LeSS calls it "just talk". The published guides for it are people-based, not meeting-based: travellers who move to another team for a sprint, scouts who observe another team's Daily Scrum, communities of practice for a shared skill, open space sessions, and the strongest one of all — communicating through the code by working on a shared codebase with continuous integration.
Basic and Huge
LeSS Basic — 2 to 8 teams
One Product Owner can hold the whole backlog in their head. All teams share one Sprint Review and one Overall Retrospective. Nothing beyond Scrum is added — this is the framework in its intended form.
LeSS Huge — 8+ teams
The backlog is divided into Requirement Areas, each with an Area Product Owner and four to eight teams. The single Product Owner remains, now ordering across areas rather than across items.
A Requirement Area is a major area of customer concern, and the rule that makes or breaks LeSS Huge is how you cut them. Areas are cut by customer-visible concern, never by technical component. An area named "checkout" is correct. An area named "database layer" recreates exactly the hand-off boundary LeSS exists to remove, and it will produce component teams with a new label within two sprints.
Each area needs at least four teams. That floor is there on purpose: an area with one or two teams is a department wearing the word "area", and it will start behaving like a separate product with its own priorities. Areas are also expected to change over time as the product shifts — they are a current view of demand, not an org chart to defend.
LeSS vs. SAFe
LeSS
- Removes roles and layers to reduce coordination need
- One Product Owner with real authority over the whole product
- Requires deep organisational change before it works
- Sprint-length planning horizon, like Scrum
- Thin documentation; principles over prescriptions
SAFe
- Adds roles and layers to manage coordination
- Product Management above several Product Owners
- Can be adopted onto the existing structure
- Program Increment horizon of 8–12 weeks
- Extensive documentation; a defined answer for each level
This is the clearest fork in scaling. LeSS asks the organisation to change so the framework fits; SAFe fits itself to the organisation. LeSS produces the better outcome where leadership genuinely commits to the reorganisation, and fails outright where it does not — there is no half-LeSS that still works, because the rules it drops are the ones holding the rest up.
How this shows up in real delivery
A LeSS adoption is an organisational design change wearing a process name. In practice it means dissolving component teams, removing a layer of middle management and giving one person authority that was previously spread across a steering group. LeSS is unusually direct about this: its own adoption guidance says to start with a deep and narrow adoption in one product group, use volunteering rather than assignment, and expect the job titles of managers to change.
The technical precondition is the one most often underestimated. One integrated Increment per sprint across eight teams is impossible without continuous integration into a shared trunk, a single Definition of Done every team meets, and an automated test suite that runs in minutes rather than overnight. Organisations that adopt the LeSS structure without that engineering base end up with several Scrum teams sharing a backlog and an integration crunch at the end of every sprint.
Where it degrades
- Several Product Owners appearing "for practical reasons", which restores the layer LeSS removed.
- Requirement Areas cut by technical component rather than by customer concern.
- Teams integrating only at the end of the sprint, so "one Increment" is an assembly scramble.
- Keeping component teams and calling them feature teams.
- A part-time Scrum Master shared across five teams, who becomes a meeting coordinator instead of changing the system.
- Skipping the Overall Retrospective, which is where the cross-team and organisational impediments were supposed to be raised.
When to use it
Use it when
- Two to eight teams work on one product and leadership will reorganise around it.
- You want the fewest possible additions to Scrum as you grow.
- One person can credibly own the ordering of the whole product backlog.
- Teams can be made genuinely cross-functional, not split by component.
- Continuous integration into a shared codebase is already working or is affordable to build.
Avoid it when
- The organisation will not dissolve component teams or middle layers.
- No single person can or will own the whole product backlog.
- The teams work on genuinely separate products — then they do not need scaling at all.
- You need a framework that layers onto the current structure without disrupting it.
- You need a detailed prescription to copy — LeSS deliberately does not provide one.
Found this useful?
Share it with someone who is working on the same problem.